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SYSTEM AND METHOD FOR REMOTE 
MONITORING AND OPERATION OF 
PERSONAL COMPUTERS 

This application is a continuation-in-part of U.S. patent 
application Ser. No. 07/966.08 i filed Ocl 23, 1992. now 
U.S. Pat. No. 5.5663 3 9 

This speculcaiion includes a microfiche appendix con- 
taining 3 hchcs having 255 frames. 

FIELD OF THE INVENTION 

The present invention relates generally to a method and 
apparatus for personal computer (PC) monitoring and con- 
trol and more specifically to a method and apparatus for 
enabling a PC to which the apparatus is connected 
(hereinafter referred to as a "Host" PC) to be accessed, 
restarted, operated and/or controlled remotely by another PC 
(hereinafter referred to as a ''Remote" PC) using standard 
public utility telephone lines or direct cabling. The invention 
further permits a Remote PC to access Host processing 
status information and/or restart (i.e reboot) the Host PC 
without Central Processing Unit (CPU) support from the 
Host PC 

BACKGROUND CF THE INVENTION 

Millions of PCs are presently in use. Each PC includes 
various hardware components including a CPU. keyboard, 
mouse, video display adapter card/circuit (hereinafter 
referred :o as "VDAC). video display monitor (hereinafter 
referred to as "VDM"). and/or one or more mas s storage 
devices. Other special purpose hardware devices such as a 
modem, voice or sound card, or network interface adapter 
card may be connected :o or installed within a PC. 

Presendy. a VDM is normally either an analog or TTL 
(digital) display device that connects to either a 15 pin or 9 
pin receptacle on a PC's VDAC. A PC's VDAC normally 
sends video signals to a VDM in either a monochrome, 
CGA. EGA, or VGA forma: known to persons familiar with 
the trade. The present invention, however, is not to be 
limited to these video formats and will operate with any 
video format when properly configured. PC's may be 
accessed and controlled remotely by other PC's by essen- 
tially two different types of processes. First a hardware 
network interface adapter card or device may be installed or 
connected to a PC. This interface device is then connected, 
either using a cable or through the airways using a wireless 
network interface device, to other PCs attached to a Local 
Area Network (LAN). All such devices require Host CPU 
support (via network interlace software installed in the PC's 
memory) to permit a Remote PC to access or control a Host 
PC. Persons familiar with the trade refer to this type of 
process as "peer to peer" PC networking. 

Second, a memory resident software system may be 
installed on a Host PC having access to a modem which 
would then permit the Host PC to be remotely controlled 
over standard telephone lines by another Remote PC having 
access to a modem and compatible memory resident inter- 
face software operating on the Remote PC Again, in this 
case the ability of the Remote PC to control and access the 
Host PC depends on CPU processing support being provided 
by both PC's and a memory resident software system being 
pre- installed on the Host PC to acknowied^ and process an 
incoming call from the Remote PC. 

Id many cases control of a PC is not always practical or 
possible remotely. Many PC based appucation software 
systems take over a PC completely and, due to memory 



restrictions or other processing conflicts, cannot co-exist 
with those software systems permitting Remote PC access. 
Moreover, even in cases where the required Host and 
Remote access interface software has been successfully 
installed if the Host processor should lock-up or otherwise 
fail, remote users immediately Lose their ability to access the 
Host system. In such cases the Remote user would not be 
able to remotely access information displayed on the Host 
PC's VDM screen after the lock-up occurred. Information 
displayed on the VDM screen, however, usually indicates 
why the failure occurred and the status of processing at the 
point of failure, and therefore can be particularly useful in 
analyzing the PC failure and in preventing future similar 
failures. 

Numerous PC monitoring systems are presently available 
to automatically alert designated persons via pagers, pre- 
recorded voice alerts or electronic mail when a PC or 
application running on a PC has failed. When such failures 
occur, the persons being notified may be in remote locations 
(e.g. at home) not able to physically access the PC that has 
failed. 

After a failure alert is issued, persons alerted typically 
have access to a Remote PC. but may not be able to access 
a desired Host PC because the Host CPU has locked up and 
will no longer respond to user input, the application running 
on the Host system does not support or condone Remote PC 
access, or the Host system does not have the required 
software installed to permit a Remote PC to access the Host 
PC. When a Host CPU has locked up or a program error has 
occurred, vital information, as to the exact nature of the 
problem which has occurred is often displayed on the PC's 
VDM screen. Normally, this information must be viewed 
and/or analyzed before corrective action can be taken. 
Devices presently exist that permit a PC to be remotely or 
automatically re -bootee, which in many cases restores nor- 
mal processing after an alert is issued. However, persons 
alerted are reluctant tc use such devices without first looking 
at the PC's VDM screen to determine what may have caused 
the failure, so that similar failures can be prevented. In other 
cases, information on the VDM screen may be necessary to 
successfully re-start an application that has failed from the 
point of failure. 

Many PC users need to remotely monitor and control 
another PC. where, due to processing restrictions or 
limitations, it may not be possible to use the PC's processor 
to access a particular PC remotely. For example, for security 
reasons, a bank may wish to discreetly monitor PC usage by 
tellers or loan officers from a central, off-site location. As a 
second example, a Network Manager may wish to periodi- 
cally remotely monitor and control, the activities of a dedi- 
cated network file server or tape backup workstation. As a 
third example, unskilled on-site PC users may need a simple 
means to permit PC maintenance personnel to have exten- 
sive remote access to their PCs. and parti cuiarly to a network 
file server, in the event of trouble or failure. 

Numerous software systems are available which are 
designed to link one PC with other PCs using modems 
connected via standard telephone lines. These systems per- 
mit a Host PC to be controlled by a Remote PC. Special 
functions keys and menus are used by these software sys- 
tems that permit these products to operate a Host PC from 
a Remote PC as if the remote user was physically sitting at 
the Host PC. Examples of such packages include Crosstalk- 
developed by Digital Cornmunications Associates. Inc.. 
1000 Alderman Dr.. Alpharetta. Ga. 30202-1000 (404-442- 
4000); Procomm Plus, developed by Datastorm Technolo- 
gies Inc., 3212 Lemone Blvd. Columbia. Mo. 65201. (314- 
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443-3282): or Unicorn, developed by Data Graphics. P.O. 
Box 58517. Renter Wash. 98058 (206-432-1201). Each of 
these products require processing support and memory from 
the Host PC and will halt if Host processing should lock-up 
or fail Also, if ihcse produ as are not pre-installed on the 
Host PC. remote access will not be possible and no provision 
is made by these products to save VDM screen history or to 
capture an active VDM screen when a PC has iocked-up. 
Finally, these prcxiucts assume software based control of the 
keyboard and/or mouse, as opposed to assuming physical 
control over the PC's keyboard and/or mouse, which is less 
restrictive. 

Network software utility programs exist that permit one 
workstation :o access and control the activities of another 
workstation connected tc the network. Products that tall into 
this category include. Carbon Copy for LANs, developed by 
Microcom Inc.. 500 River Ridge Drive, Norwood, Mass. 
02062 (617-551-10O0): and Map Assist, developed by Fresh 
Technology Company. 1478 North Tech Boulevard, Suite 
101. Gilbert Arizona. 85234 (602-497-4200). Similar to the 
other remote access utility programs, these products require 
software resident in the Host PC's memory to operate. 
Neither remote centre 1 or access will be possible if the Host 
PC should lock-up or fail 

Utility software programs exist that are designed to con- 
vert graphics image data captured by document scanners 
into text data, so that lie resulting text data can be manipu- 
lated and edited using word processing software products. 
Examples of such programs include, OmniPage 
Professional, de*. eloped by Caere Corp. 100 Cooper Ct.. Los 
Gatos. Calif. 95030 1 408-395-7000); Perceive, developed by 
Ocron, 3350 Scoc Blvd.. #36. Santa Clara. Calif. 95054; 
TypeReader. developed by ExperVTsion Inc.. 3590 N. First 
St.. San Jose. Calif. 95 134 (408-428-94-44); and WordScan 
Plus, developed by Caiera Recognition Systems. 475 Potr- 
ero Ave.. Sunnyvale. Calif. 94086 (408- 720-8300). Such 
programs obtain sc-urcc input data from digitized output of 
static data files created by document scanners as opposed to 
capturing, decoding then converting to text the output sig- 
nals of a PC' s video display adapter cards/circuits (VDAC) 
as the signals are occurring (i.e. on a real time basis). In 
addition, such utility programs depend on CPU support from 
the PC where they ar: installed, cannot transmit data related 
to the status of processing in the event the PC should fail, 
and provide for no remote keyboard and/or mouse control. 

Devices exist that permit using a central keyboard and 
monitor to control and access multiple PC's. Examples of 
such products include Commander, developed by Cybex 
Corporation. 280G-H Bob Wallace Ave Huntsville. Ala 
(205-534-0011;: Master Console developed by Raritan 
Computer. Inc.. 10-1 Dene Court. Belle Mead. NJ. 08502: 
and Plex developed by Data Vision Inc. 370 West Carnino 
Gardens Blvd. Boca Raton, Fla.. 33432 (407-482-3996). 
These products require the keyboard and PC interface cables 
to be directly connected to one or more physical cable 
switching device* s). The VDAC signals are merely boosted 
and transferred as video signals over direct dedicated 
cabling. No attempt ls made to convert the signal output of 
the VDAC to a digiizl form suitable transmission over public 
utility telephone lines or other communication network. 
Similarly, the keyboard used by the central unit is connected 
directly to each PC controlled with local wiring and no 
attempt is made to control keyboards using the public 
telephone system or to support keyboards existing at both 
the remote console and Host PC. 

Devices exist that transmit a composite (TV) video signal 
over a telephone line. Such products include the 
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Phone Viewer, distributed by Home Automation Lab. 5500 
Highlands Pkwy. Suite 450. Smyrna, Ga. 30082-5141 and 
AT&T's video phone, developed by AT&T. 14250 Clayton 
Road. Baldwin. Mo. 63011, 1-300-437-9504. These prod- 
ucts rely on a video camera to periodically capture a picture 
which is then transmitted to a screen oo the remote caller's 
video phone. These sysxems convert the video camera 
images captured to bit-mapped graphical images. No 
acrempt is made to decode the data captured into text data. 
Furthermore, such products are not capable of decoding and 
transmitting the video signals produced by a PC's VDaC If 
such products were used to simply snap a picture of the PC's 
VDM screen, the resulting data transmitted would be slow 
and of a poor quality, particularly if the PC video output 
changed during the period when the video snapshot is being; 
taken. Moreover, none of these products provide a PC 
keyboard/mouse telephone interface necessary to control a 
Remote PC. Even if such an interface were provided, the 
user may require a separate phone line to access the Remote 
PC. so as to not interfere with me transmission of video 
graphics image data derived from the composite video 
snapshot. 

Devices exist that permit a video signal to be captured by 
a PC from an external analog video recording device, such 
as a video camera, and the signal converted into a digital 
format suitable for display on a PC's VDM using a video 
capture adapter card inserted into a PC. One such device is 
the Smart Video Recorder manufactured by Intel Corp.. P.O. 
box 58130. Santa Clara. Calif. 95052 (800-955-5599). Such 
devices require a dedicated cable to be directly connected 
from the video capture adapter card to the video recording 
device, and none of these products provide a PC keyboard/ 
mouse telephone interface necessary to control a Remote 
PC. 

Numerous devices exist that permit a PC to be re-booted 
remotely such as the Sentry Remote Power Manager, devel- 
oped by Server Technology. 2332-B Walsh Ave. Santa Clara. 
Calif. 95051 (408-983-0142). Tone Operated Switch 
(TOPS) developed by Black Box Corp.. P.O. Box 12800. 
Pittsburgh Pa. 15241 (412-746-5530) or TELHBOOT devel- 
oped by Fox Network Systems. 15200 Shady Grove Road. 
Suite 350. Rockville Md. 20750 (301-924-2264). Once such 
system is described in U.S. patent application Ser. No. 
07/966.081 filed Oct. 23. 1992 and assigned to assignee of 
the present invention, the contents of which are incorporated 
by reference herein. These devices, however, provide no 
remote video display or keyboard/mouse interface capabili- 
ties. 

U.S. Pat, No. 5,153.886 to Tuttle discloses a visual 
display signal processing system and method used for 
regression testing of computer hardware and/or software 
applications. The system disclosed in Tuttle. however, reues 
upon connection to the internal video adapter circuitry and 
docs not operate to interpret video raster signals generated 
by the video display adapter circuit. Furthermore, the system 
disclosed in Tuttle is intrusive since it requires a circuit card 
to be installed into a computer to be tested, and cannot be 
easily connected to a computing device using the existing 
standard interface connectors. 

U.S. Pat. No. 5.0S4.875 to Weinberger et al. discloses a 
system for automatically monitoring copiers Srora a remote 
location and allowing operation of a copier from a remote 
location. Weinberger et al.. however, does oof disclose a 
system suitable for use in remote monitoring and controi of 
a personal computer system or network, and further does not 
disclose a system which can monitor and forward video 
raster signals generated by a remote computer system. 



U.S. Pat. No. 5.124.622 to Kawamura et ai discloses a 
system for remote diagnosis of a numerical apparatus. 
Again, however. Kawamura et ai. does aot disclose a system 
which can monitor and forward video raster signals gener- 
ated by a remote computer system. Additionally Kawamura 
et al does aot disclose a system for use in remote monitoring 
and control of 2 personal computer system or network. 

U.S. PaL No 5237.677 to Hirosawa st al. discloses a 
monitoring and controlling system and method for a data 
processing system in which report of a fault occurrence is 
automatically -fectuared to a remotely located supervision/ 
control system. Hirosawa et ai.. however, fails to disclose a 
system that can monitor me video raster signals generated by 
a remote data processing system. 

SUMMARY OF THE INVENTION 

The present invention permits a Remote PC to access and 
control a Host PC. The system includes a microprocessor 
controlled computer hardware device, (hereinafter referred 
to as a "Host Umc"). software programs operating on the 
Host PC. and software programs operating on the Remote 
PC. 

The connection between a Host PC and Remote PC can be 
accomplished through either of two means. As a first means, 
a modem :s connected to the Remote PCs serial interface 
port and a compatible modem is connected to a data inter- 
face port on *he Host Unit. On this basis, a Remote PC could 
communicate with a Host site via a standard telephone line 
linkage between -he two modems. This means is hereinafter 
referred to as a "Modem Linkage" 

As a second means, a remote PC could be connected by 
a dedicated cable from a data transfer port of the PC (e.g. a 
serial or parallel port; directly to a data interface port on the 
Host Unit. This means is hereinafter referred to as a "Direct 
Line Linkage". The Direct Line Linkage means supports 
greater data transfer rates than the Modem Linkage means 
and the Direct Line Linkage means avoids the need to use 
modems. However, the Direct Line Linkag e means does not 
provide the same 3exfoility for off site remote access to a 
Host Unit as does the Modem Linkage means. 

The Host Unit contains it's own microprocessor (or other 
computing circuitry; designed to capture, interpret and store 
information displayed on a Host PC's VDM screen from the 
video raster signal output of the Host PC's VDAC (i.e. a 
video raster signal is that video output signal of a VDAC 
which serves as direct input into a VDM). VDM screen data 
collected in this manner permits a Remote user to access, 
obtain, view, and store Host PC current and previous VDM 
screen data on a Remote PC after linking the Remote PC to 
the Host Unit, VDM screen data captured, interpreted and 
stored by a Host Unit from the Host PC's VDAC raster 
output may be either text or graphics (i.e. image) based and 
may be in either color or monochrome. Host VDAC video 
raster signal output display formats captured and interpreted 
by a Host Unit include monochrome. CGA. EGA. and VGA 
modes, which are known to persons familiar with the trade, 
and similar techniques could be used for any display format. 

In addition, the invention permits a Remote PC to (1) 
physically redirect keyboard and/or mouse control from a 
keyboard and/or mouse connected to a Host PC at the Host 
Site to the keyboard and/or mouse connected to the Remote 
PC. thereby allowing the Remote PC to fully control key- 
board and/or mouse input to the Host PC, (2) remotely 
initiate software programs installed on a Host PC necessary 
to transfer files and data between the Host PC and Remote 
PC. (3) interconnect (Le. daisy chain) multiple Host Units 



together so as to allow a Remote PC to switch between 
different Host PC's during a single access session, and (4) 
coid boot a Hcst PC. when necessary by instructing the Host 
Unit to temporarily cut the AC power to the Host PC forcing 
it to perform a coid boot. 

One embodiment of the present invention comprises (I) 
software installed on the Remote PC that permits the 
Remote PC to utilize a standard modem such as. for 
example, a Hayes 9600 baud Ultra modem, Hayes 2400 
Smart modem ^ Boca 14.4 for Modem Linkage, or a direct 
cable connection fcr Dtrec: Line Linkage, to remotely access 
a Host Unit, tiiercby allowing me Remote PC to communi- 
cate with the Host Unit and access/control a Host PC 
attached to the Hosi Unit: (2) a Host Unit, which is either (a) 
directly attached :o a modem or remote PC or (b) connected 
to a Remote PC via another Host Unit (t.e daisy chained) and 
is directly connected to the keyboard input, optional mouse 
input. VDaC raster output and AC power input interfaces of 
the Host PC; (3) software program files installed on the Host 
PC that may be activated remotely to facilitate file transfers 
between the Host and Remote PCs and (4) software pro- 
grams run on the Host PC during installation to permit the 
Host Unit attached to the Host PC to automatically train 
itself how to decode the specific video raster output signals 
from the Host PC's VDAC 

Software installed on the Remote PC permits (1) access- 
ing a Host PC site in either a Modem Linkage or Direct Line 
Linkage mode. (2) initializing a modem attached to the 
Remote PC (including baud rate, and initialization strings) 
necessary for a Modem Linkage mode. (3) maintaining a list 
of Host Units that may be accessed from the Remote PC 
(including the dialing information needed to call the Host 
modem that is ased to access each Host Unit (when in a 
Modem Linkage mode), the ID number for each Host Unit, 
and the password needed to access each Host Unit). (4) 
completing a Modem or Direct Line Linkage from the 
Remote PC to a designated Host Unit. (5) displaying status 
information relating to a active connection on the Remote 
PC's VDM screen. (6) scanning the Host PC's VDM screen 
display history transferred from the Host Unit and stored on 
a mass storage device on the Remote PC. (7) setting the 
specific procedure to be used by the active Host Unit to 
capture Host PC VDAC video raster output (i.e. text modes, 
graphic modes, etc. in either monochrome or color). (8) 
switching me Remote PC s keyboard and/or mouse from use 
as a normal Remote keyboard and/or mouse to use as the 
keyboard and/or mouse for the Host PC. (9) accessing a Host 
PC for purposes of viewing a Host PC's VDM activity 
without switching the Host PC's keyboard and/or mouse to 
the Remote PC's keyboard and/or mouse. ( 10) switching the 
keyboard and/or mouse back from use as Host PC keyboard/ 
mouse to use as a Remote keyboard/mouse. (11) initiating 
and controlling the transfer of darn riles between the Host 
and Remote PC. (12) communicating with the Host Unit 
using either standard telephone lines and modem commu- 
nication protocols, when in a Modem Linkage mode, or a 
direct dedicated line, when in a Direct Line Linkage mode. 
( 13) switching the Remote PC's VDM screen from a normal 
(Le. Remote; VDM screen mode to a Host screen mode 
where a Host PC's VDAC output data is captured (without 
Host PC CPU support) and transmitted by the Host Unit to 
the Remote PC and is displayed on the Remote PC's VDM 
screen in place of the normal Remote PC's VDM screen 
display, (14) switching the Remote PC's VDM screen back 
from a Host PC video display to use as a Remote PC video 
display. (15) notifying the Host Unit to temporarily cut AC 
power input to the Host PC thereby forcing the Host PC to 
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re-start, which is commonly referred to in the trade as a 
"cold-boot." (16; switching between Host Units and the 
Host Unit's associated Host PC in cases where more than 
Host Unit is interconnected. (17) changing a Host Unit's 
permanent or temporary password used by Remote PC's to 
access the Host t so as to preveat the unauthorized access 
of a Remote jser to a Host PC. (18) terminating a Modem 
Linkage or Direct Line Linkage to a Host. (19) initiating a 
connection :c anctner site, as required. (20) storing proce- 
dures necessary tc Drain a Host Unit to decode a particular 
Host PC's VDaC video raster output signal, so that such 
procedures can be reloaded by a Remote PC into the Host 
PC's memory to facilitate using one Host Unit to access 
more than one Host PC without the need to repeat on-site 
training, and (21 \ eating Remote PC application processing 
when there is no ;onger a need to access Host PCs. 

A Host Unit can connect (via cable and adapters) to a Host 
PC and is capable ox (I) verifying a remote user's password 
entered to access i*c Host Unit, so that access to the Host PC 
will be denied in cases where an invalid password is 
received: (2) permiemg a Remote PC to optionally take over 
the Host PC's keyboard and/or mouse by ignoring any input 
from the Host PC keyboard and/or mouse and accepting 
only keyboard and/or mouse input from the Remote PC's 
keyboard received through a Modem Linkage or Direct Line 
Linkage: C3; pemnamg a user located at a Host site to take 
back cootroi of a Host PC's keyboard and/or mouse by 
depressing a momentary switch button on the Host Unit; (4) 
passing though the Host PC's keyboard and/or mouse input 
signals to the Host PC via input and output keyboard and/or 
mouse connectors on the Host Unit: (5) intercepting, storing, 
analyzing, decoding and men passing through the Host PC's 
VDAC video raster SLgnai to the Host PC's VDM screen 
display via input and output video connectors on the Host 
Unit, even in cases where a Remote PC is not accessing the 
Host unit; (6) decoding the Host PC's VDAC video raster 
output signals to either text or bit-mapped graphics format; 
(7) identifying and storing, as necessary, VDAC data that 
has changed between each VDAC refresh cycle: (8) 
compressing, transmitting and storing the changes in text or 
graphics data decoded from the VDAC raster output signal 
of the Host PC to a Remote PC; (9) supplying input/output 
interface cable receptacles to permit Host Units to be daisy 
chained with cacn other so as to allow a Remote PC to 
switch between, and remotely controL multiple Host PC's 
over a single phone line and modem daring a single phone 
call; (10) supplying AC power to the Host PC. through an 
AC output connector, so as to permit the Host Unit when 
desired, to temporarily cut power to a Host PC forcing the 
Host PC to reboot 

VDAC video raster output signals from a Host PC's 
VDAC circuits may vary from PC to PC (or adapter circuit 
to adapter circuit) making it impossible to utilize a standard 
process to decode the signal. During installation of the Host 
Unit, software supplied with the apparatus may be activated 
on the Host PC to train the Host Unit to properly decode the 
text mode VDAC video raster output of the Host PC. During 
' this one time training process, predetermined text and char- 
acter strings are displayed using software supplied with the 
Host Unit via the Host PC's VDAC. The resulting video 
raster output signal of the PC's VDAC is then analyzed by 
the Host Unit's processors to determine the exact procedures 
needed to convert the VDAC raster output signals to known 
text data or graphics pixel data displayed during me training 
process. The results of this training process yields the 
specific procedures and data needed to decode and capture 
text data or graphics pixel data from the VDAC output of a 
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specific PC. Such procedures and data are stored In non- 
volatile RAM contained in the Host Unit, so that the training 
process fcr a specific Host PC need not be repeated unless 
the Host PC's VDAC is changed. This training process 
permits :he Host Unit to interface with any of the PC 
monochrome or color VDAC standards, such as CGA. EGA. 
or VGA familiar ro persons in the trade. On request by a 
Remote PC said training procedures needed to decode a 
given Host PC's VDAC signal may be copied to a file on a 
mass storage device connected to the Remote PC. This 
procedure M/ould then permit the Remote PC to reset the 
decode procedure used by a Host Unit to support situations 
where a single Host Unit at a site is switched between 
different PC's by user's on site to facilitate remote diagnos- 
tics of a PC that has failed. 

A less preferred embodiment of the present invention 
could be employed in which the video capture function of 
the Host Unit is accomplished by inserting an adapter card 
into one of *hc I/O buss adapter slots in the PC. This adapter 
card would have it's own microprocessor, or other process- 
ing circuitry, that would independently capture and store a 
PC's Basic Input Output System (BIOS) video data for 
transmission to the Host Unit over a cable interface from the 
adapter card to the Host Unit There are several reasons why 
this crribodimcnt of the present invention is less preferred: 

A. Many PC's now operate in a graphics VDM screen 
mode as opposed to a text VDM screen mode where data is 
displayed through the PCs internal BIOS (Basic Input/ 
Output System) by setting pixels on a VDM screen as 
opposed to sending standard character format data to the 
VDM screen. The Windows™ operating system developed 
by Microsoft Corporation is an example of a such a graphics 
user interface software operating system. In a graphics VDM 
screen mode numerous VDM standards exist that define 
number, placement and intensity options available for dis- 
playing graphics information on the VDM screen. Software 
drivers from the various PC application manufactures may 
modify or circumvent traditional BIOS functions to display 
data on the VDM screen. As the result, the process of 
decoding graphics information at this level is more diversi- 
fied and subject to more change than the preferred embodi- 
ment of decoding the actual VDAC video raster output 
signal which conforms to a relatively fixed standard (Le. the 
input to a VDM). 

B. Some PC's have motherboards with "built-in'* video 
circuitry on the motherboard, which may not permit the user 
to disable video processing and/or may not pass video data 
across the PC's buss. 

C Inserting an adapter card into a PC requires shutting off 
the PC's power then opening the PC to insert the adapter 
card. Such a procedure is not viewed as acceptable to the 
user as simply attaching interface cables from the Host Unit 
to the VDAC interface port on the PC. Moreover, opening 
the PC to install the adapter card would make it difficult and 
time consuming for unskilled personnel at an off-site loca- 
tion to setup a spare Host Unit on a failed Host PC for 
remote diagnostic and/ or repair by a off-site maintenance 
operation. 

D. The size of the PC adapter card must remain within 
fixed size limits. Such Limits could constrain the level of 
functionality that could be incorporated into the card. 

E. The I/O buss adapter slot, power, etc. within the Host 
PC could fail which would prevent the Host Unit from 
transferring any stored video data from the Host PC. 

F. An additional adapter card is required, which may 
preclude users without an available buss adapter slot from 
installing the apparatus. 



A second less preferred embodiment similar to that dis- 
cussed above, could be used where a dual function video I/O 
adapter card could be engineered and inserted in a PC's I/O 
buss adapter slot in place of the PC's existing video I/O 
board. One function of this adapter card would be to provide 
video ourp'-it :o a VDM screen using standard video con- 
nector plugs. The other function of the adapter card would 
be capture the video BIOS data using additional circuitry on 
the I/O adapter card and transmit this data to a remote PC. 
In this case, die video adapter card would conform to 
standard, pre-4e:ined video display options and thereby 
avoid the different drivers and display approaches taken by 
the various video adapter card manufacturers. There are 
several reasons why this preferred embodiment of the 
present Invention is less preferred: 

A- Insernng an I/O buss adapter card into a PC requires 
shutting off tne PC's power and then opening the PC to 
insert the card Such a procedure would not be as acceptable 
for the user as simply attaching interface cables from the 
Host Una to the VDAC interface port on the PC. Moreover, 
opening the PC to install the adapter card would maice it 
difficult and time consuming for unskilled personnel at an off 
sice location to setup a spare Host Unit oo a failed Host PC 
for remote diagnostic and/or repair by a off site maintenance 
operanon. 

B. Some PC's have motherboards with "built-in" video 
circuitry on the motherooard, which may not permit the user 
to disable video processing and/or may not pass video data 
across the PC's buss. 

C. The size of the adapter card must remain within fixed 
size limits. Such limits could constrain the level of features 
that could be incorporated into an adapter card with dual 
functionality. 

D. The I/O buss adapter slot, power, etc. in the Host PC 
could fail %hich would prevent the Host Unit from trans- 
ferring any video data from the Host PC. 

Other less preferred ernixxiiments of the present invention 
could also be employed where one. several, or all of the 
remaining functions of the Host Unit could be placed oo one 
or more adapter cards using an approach similar to that 
discussed ascve for other less preferred embodiments of the 
present invention. For example, a special adapter cable 
could be connected to the end of a keyboard cable's plug and 
plugged into an input jack of a keyboard interface adapter 
card. Then, another adapter cable could be plugged into a 
output jack of the keyboard interface adapter card and the 
other end of the cable plugged into the normal input key- 
board plug on the PC. The keyboard adapter card would 
contain a microprocessor and circuitry designed to perform 
the keyboard processing function described above for the 
Host Unit. There are several reasons why this preferred 
erribodiment of the present invention is less preferred: 

A. The iiiultipie interface boards would be more costly to 
design and would require the production of non-standard 
interface cables. 

B. Some PC's have motherboards with "built-in" video 
circuitry on the motherboard, which may not permit the user 
to disable video processing and/or may not pass video data 
across the PC's buss. 

C. Inserting an VO buss adapter card into a PC requires 
shutting off the PC's power and then opening the PC to 
insert the card. Such a procedure would not be as acceptable 
for the user as simply attaching interface cables from the 
Host Unit to the various interface ports on the PC or on other 
Host Units. Moreover, opening the PC to install the adapter 
card would make it difficult and time consuming for 
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unskilled personnel at an off site location to setup a spare 
Host Unit on a failed Host PC for remote diagnostic and/or 
repair by a off Tite maintenance operation. 

D. The size of a adapter card must remain within strict 
size limits. Sucn limits couid constrain the level of func- 
tionality that cou.d be incorporated into the card. 

E. Multiple adapter cards may be required, which may 
preclude users with insufficient available buss adapter slots 
from installing 'he apparatus. 

F. The I/O buss adapter slot power, etc. in the Host PC 
could fail which would prevent the functions now being 
performed by the Host Unit from being performed within the 
Host PC's adapter cardfs;. 

From the above, it will be readily seen that one object of 
the present invention Is to allow a user at a first location to 
view information displayed on a video display terminal, or 
monitor, of a data processing device at second location 

Yet another object of the present inveation is to allow a 
user to view the information on the video display terminal 
even if the data processing device at the secon<t location is 
locked up and ao longer processing data or input commands. 

A still further object of the present invention is to allow 
the user at the first location to give commands to the data 
processing device at the second location in such a manner 
that the data processing device perceives the commands as 
corning from a standard input device typically attached to 
the data processing device such as a keyboard or mouse. 

Another object of the present invention is provide for the 
temporary interruption of AC power to the data processing 
device at the second location in response to a command from 
the user to force the data processing device to initiate a cold 
boot, or power on routine. 

Yet another object of the present invention is provide a 
system and method in which video display information 
contained in a video raster signal output from a video display 
circuit of a data processing device is analyzed to determine 
the content of the signal and to convert the signal into a form 
suitable for transmission over a standard public telephone 
line or other cornmunicarions network. 

A still further objective of the present invention is to 
provide a system and method for training the apparatus to 
recognize different display formats mat are used to transmit 
information from a video display circuit to a video display 
terminal or monitor. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The drawings consist of 7 figures numbered 1 to 7. 
Figures that consist of more than one sheet contain a unique 
alphabetic suffix for each sheet. When a figure is referred to 
in it's entirety, the alphabetic suffix is omitted. A brief 
description of each figure is as follows: 

FIG. 1 is a functional overview of the invention. 

FIG. 2 is a front external view of the Host Unit. 

FIG. 3 is a rear external view of the Host Unit. 

FIG. 4A— 4P-5 are engineering diagrams representing an 
overview of the internal circuitry of the Host Unit 

FIG. 5 A— 51-2 are block diagrams describing the micro- 
processor based software operating system controlling pro- 
cessing occiirring in the Host Unit. 

FIG. 6A1— 6D arc block diagrams describing the process 
of training the Host Unit to recognize text for a specific PC. 

FIG. 7A-7G are block diagrams describing the software 
operating on the Remote PC. 

FIG. 8-A1 to 8-B-2 illustrate the current protocol used to 
communicate between a Remote PC and a Host Unit. 
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FIG > illustrates an alternative embodiment of the present 
invention implemented on a circuit card suitable for inser- 
tion .nto a lata processing device. 

The microfiche appendix, part 1 contains a detailed pans 
list of the parts presently included on the Host Unit's printed 
circuit ^oard. cross-referenced to detailed electrical circuit 
schematics presently employed within the Host Unit, which 
are provided as part 2 of the microfiche appendix. Also, the 
micron che appendix includes the detailed application and 
operatic 2 system software source code presently used for the 
apparatus. 

DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

FIG. 1 is a operational overview of the invention. Rect- 
angular objects on this diagram represent physical (i.e. 
hardware; components of the apparatus. Dashed rectangular 
boxes represent groupings of related hardware components 
at different locations, dashed lines represent cables or cords, 
a solid Jne represents a communications interface (e.g. a 
telephone Line or dedicated communications line), a arrow 
on the end of a line represents the direction that data or 
power 3ows and a line with no arrows indicates that data 
Sows in ooth directions. 

A PC located at a Remote Site I may be used to access a 
Host System 6. The Remote PC 2 may be equipped with a 
VDAC and monitor 3. a keyboard 4 and a Hayes compatible 
Modem 5 familiar Co persons in the trade to access a remote 
site via a Modem Linkage. No modem is necessary to access 
a Host Unit m cases where a Direct Line Linkage is used 
instead of a Modem Linkage. A Mouse 4A may also be 
connected to the Remote PC. 

Software installed m me Remote PC 2, permits the 
Remote PC to initiate a call via the Remote PC's Modem 5 
to a Host Site's Modem 7 over a standard phone line or to 
make a direct linkage via a dedicated Direct Line Linkage, 
The apparatus currently supports up to 19.2 kb data transfer 
rates between a Remote PC 1 and Host System 6 or between 
a Host Unit 8 and another Host Unit 13 or 18, but the speed 
of data transfer could be higher or lower and still fulfil the 
objects of the invention. 

Host Units 8. 13. 18 may be daisy chained together to 
permit a Remote PC to switch between Host Units during a 
single access session. A group of Host Units connected 
together on a single daisy chain is herein referred to as a 
"Host Site.** Software provided with me apparatus permits a 
Remote PC to access more than one Host Site, but. presently 
access to one Host site must be terminated before a different 
Host site may be accessed. 

Host Units 8. 13, 18 are identified by a unique number set 
by DIP switches located in each Host Unit. There are a total 
of six DIP switches in a Host Unit available to set a specific 
Host Unit ID number, so the Host Unit ID may be set by a 
user to yield a decimal number between 00-63 depending on 
!he positions of the switches. Of course, additional switches 
could be provided to allow for addressing of a greater 
number of Host Units. Presently. Host Unit 00 8 must be 
connected to the Modem interface 7 via a modem cable from 
"Data In" 7Q (shown in FIG. 3) receptacle of the Host Unit 
to the serial interface receptacle on the modem or must have 
a Direct Line Linkage via a dedicated cable from the "Data 
In" 70 (FIG. 3) receptacle of the Host Unit to a serial 
interface port on the Remote PC. An RJ-12 cable with serial 
port interface cable adapters can be used for either purpose. 
Although any suitable cable could be used, the RJ- 12 cable 
has six conductors, two of which are available for serial 
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communications. Other Host Units may then be connected 
in a Daisy Cham fashion using a cable from the "Data Out** 
71 (FIG. 3) receptacle on the last Host Unit in the Daisy 
Chain 13 to the "Data In" 70 (FIG. 3) of the newly connected 
Host Unit 18. Host Units connected together in a daisy chain 
presently use R J- 12 cable for the connection from Host Unit 
to Host Unit, but any cable could be used with the appro- 
priate conductors therein. In order for a Remote PC to 
communicate with a specific Host Unit on a daisy chain* 
each Host Unit must have a unique H> number assigned from 
01 to 63. Ail data packets sent from the Remote PC to a 
particular Host Unit on a daisy chain use the Host Unit ID 
to address the transmitted data packet to a specific Host Unit 
number for a response. Presently, a Remote PC may only 
access one Host Unit at a time, but may switch been Host 
Units during a single active communications session. 

A Host Unit 8 receives it's power from an AC electrical 
power source via an AC power cord connected to an U AC 
Power" 61 (FIG. 3) receptacle on the Host Unit. The Host 
Unit also supplies AC power to the Host PC 10 to which it 
is connected through an AC power cord going from the "AC 
To PC 62 (FIG. 3) receptacle on the Host Unit to the AC 
power supply input on the Host PC. By supplying power to 
the Host PC in this manner, AC power to the Host PC may 
be temporarily cut by the Host Unit when instructed by a 
remote user's Remote PC to force a iocked-up Host PC to 
cold-boot, so that normal Host PC processing can be 
restored remotely. This "cold-boot'* procedure is particularly 
useful when the Host PC will no longer respond to any 
keyboard or other input. The Host PC is turned off and back 
on by the remote user, thereby reinitializing the Host PC's 
processing circuitry. 

When a Host Unit 8 is first connected to a Host PC 10. the 
Host PC's keyboard 11 is disconnected from the keyboard 
input jack and plugged into a "Keyboard Input From KB" 68 
(FIG. 3) receptacle on the Host Unit Then, a Keyboard 
Cable supplied with the apparatus is plugged into the 
"Keyboard Output To PC 69 (FIG. 3) receptacle on the 
Host Unit and the other end of mis cable is plugged into the 
keyboard input jack on the Host PC. In this manner, the 
keyboard's signals go through Host Unit to the Host PC. 
which permits the Host Unit to interrupt Host keyboard 
signals and redirect keyboard input to utilize the Remote 
PC's keyboard instead of the Host PC's keyboard. 
Therefore, a Host PC need not have a Keyboard 11 present 
in order to facilitate Keyboard 4 data input and control of the 
Host PC by a Remote PC. With regard to the Remote PC's 
Keyboard 4. when the Remote PC 2 is accessing a Host Unit, 
the Remote PC's keyboard input is also captured by a 
software program running on the Remote PC supplied with 
the apparatus and redirected out of the Remote PC to the 
Host Unit 8 for input into the Host PC 10 via either a Modem 
(5 to 7) or Direct Line Linkage (2 to 8). 

Similar to keyboard cabling, the Host PC's video cable 
from the Host PC's video display 9 (VDM) is disconnected 
from the Host PC's VDAC and plugged into cither the Host 
Unit's 8 15 pin "VGA Out" 64 (FIG 3) or 9 pin "Video Out" 
66 (FIG. 3) receptacle depending on the number of pins on 
the video cable's connector. Then, either the corresponding 
9 pin or 15 pin video cable supplied with the apparatus is 
plugged into the appropriate 15 pin "VGA In" 65 (FIG. 3) 
or 9 pin "Video In" 67 (FIG 3) receptacle on the Host Unit 
S aad the other end of the video cable is plugged into the 
Host PC's video display 9 (VDAC). This configuration 
allows the Host PC's video display 9 (VDAC) output 
signals, including the video raster signals, to pass through 
the Host Unit $. so that the Host Unit can access, scan and 
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decode the siguals into cither bit image, or monochrome or 
color text data and oiso store the most recent data (up to the 
internal storage capacity of the Host Unit) for transmission 
to a Remote PC wnen requested. 

A senai cabie can be connected from one of the Host PC's 
communications pons to a "SeriaT 1 ' 72 (FIG. 3) receptacle on 
the Host Unit 8. This connection permits data file transfers 
to occur between a mass storage device on a Remote PC 2 
and the Host PC 10 This connection also permits data from 
a Remote PC's Mocse 4 A to be transmitted to the Host PC's 
senal port through the Host Unit's Serial 72 (FIG. 3) 
interface. Mouse input 4A from a Remote PC is captured by 
software running on the Remote PC (supplied with the 
apparatus , and redirected out of the Remote PC 2 to the Host 
Unit 8 for input .mo :he Host PC 10. 

When a Host Unit 8 is first connected to a Host PC 10, the 
Host PC T s serial Mouse 11A (if present) is disconnected 
from the Host PC's serial port and plugged into a "Mouse" 
73 (FIG. 3) receptacle on the Host Unit. This permits Mouse 
1LA signals to pass through Host Unit to the Host PC via the 
"Serial" 72 (FIG. 3; port interface on the Host Unit 3. This 
approach permits the Host Unit 8 to interrupt any Host PC 
Mouse 11A input signals and redirect mouse data input to 
utilize the Remote PC' s Mouse 4A instead of the Host PC's 
Mouse 11 A. On this basis, a Host PC need not have a Mouse 
11 A present m order :o facilitate Mouse 4A data inpMt and 
control of the Host PC by a Remote PC. A mouse interface 
could exist on any Host Unit on a daisy chain (e.g. Host Unit 
01 13. Uoil. 18, etc.). 

A nzicrcprocesscr and software located in each Host Unit 
on a daisy chain 8. 13. 18 looks for communication data 
packets sent from a Remote PC addressed individually to the 
Host Unit' 5 ID number. When received, codes contained in 
the data packet define the nature of a Remote PC's process- 
ing request. For example, a data packet may contain a code 
requesting me Host Unit to verify that a password contained 
in the packet is correct. If the password is correct, the Host 
Unit transmits a data packet back to the Remote PC with a 
code indicating the password had been verified. Otherwise, 
a data packet containing a code indicating that the password 
was incorrect is returned to the Remote PC. Similar data 
packet requests and responses would be sent over the 
communication line in ten aces for other remaining functions 
of the system. 

A second microprocessor, memory storage and software 
also exists in each Host Unit. The primary purpose of this 
microprocessor and related operating system software is to 
capture, decode, store and transmit individual Host PC 
VDAC data to a Remote PC. Although the most preferred 
embodiment of present invention contains two microproces- 
sors to handle the video analysis and the communications 
with a remote PC, it is contemplated that these functions 
could be performed by a single microprocessor having 
sufficient computing power to conduct both operations. 
Notably, as microprocessor technology continues to evolve, 
it is possible that a single processor system could be 
developed, thereby increasing reliability and reducing costs. 

Host System Oi 12 and Host System.. 17 represent 
examples of how other Host Unit/Host PC configurations 
can be daisy chained at a site, so that one Modem or Direct 
Line Linkage could be used to rjermit a Remote PC to switch 
between multiple Host Units during a single communica- 
tions session. The "..** in the "Unit,." and "Host System..** 
identifiers on FIG. 1 are used to indicate one or more 
additional Host Units may exist on the daisy chain. The 
maximum number of Host Units depends on the available 
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number of bits used for each Host Unit address, and the most 
preferred embodiment supports up to 64 Host Units at any 
one Host Site. These other Host System configurations are 
connected to their respective Host PCs in the same manner 
as described above for Host Unit 00 8. More specifically. 
Host Unit 01 13 and Host UniL. 18 are connected to video 
displays 15. 19; Host PCs 16. 20; and Keyboards 17. 21 
using the same procedures described for Host Unit 00 8 
above, except the last Host Unit in the daisy chain would not 
have a daisy chain cabie connected to the Host Unit's "Data 
Out" 71 (FIG. 3; receptacle. Software installed on a Remote 
PC (provided with the apparatus) permits a Remote PC to 
access more than one Host Site, but access to one Host site 
must be ended before access to another Host site can begin 
(Le. no more than one Host Site may be accessed at a time). 

FIG. 2 details a frontal view of a Host Unit. The front 
panel of the Host Unit includes five status indicator lights 
54-54 and an "Action" momentary switch 55. Ail five 
indicator lights will be off until the ON/OFF power switch, 
located on the right rear side of the Host Unit is turned ON. 

A detailed description of the purpose of each of the five 
indicator lights going from left to right is as follows: 
AC Power 50 — This light indicates that the Host Unit's 
on/off switch is in the "on" position and AC power is 
being received into the Host Unit. 
Keyboard Local 51 — This light indicates the keyboard/ 

mouse attached to the Host Unit is available fcr use. 
Keyboard Remote 52 — This light indicates a remote user 
is accessing the Host UniL If the light is blinki ng, it 
means a remote user is in the process of connecting to 
the Host Unit or has been previously blocked by a Host 
PC user from tajeng over the keyboard. If the light is 
OK. it means a remote user has taicen over the Host 
PC's keyboard anchor mouse. 
Daisy Chain 53 — This light presently blinks periodically 
indicating a remote user is currently connected to one 
of uie Host Unit's on the daisy chain. If no remote user 
is accessing a Host Unit on the daisy chain, the light 
will be off. 

Setup Mode 54 — This light blinks during the initial 
training or re -configuration of the Host Unit to indicate 
the Host Unit is properly linked to the Host PC This 
light also blinks when file transfers are occurring 
between a Remote PC and Host PC. 

If someone is using a Host PC' s keyboard and/or mouse 
when a Remote PC attempts to take over the Host PC. a user 
at a Host PC site may wish to retain control of the Host PC's 
keyboard and/ or mouse by depressing the Action 55 momen- 
tary switch. Only one user can have control of the Host PC's 
keyboard and/or mouse at any point in time. In cases of 
conflict, the user at the Host site has the final authority to 
determine who controls the Host system's keyboard and/or 
mouse. Control may be passed back and forth by depressing 
the Action 55 momentary switch. Regardless of who has 
current control of the Host Unit ' s keyboard and/or mouse, a 
remote user will have the ability to view the Host PC's VDM 
screen remotely on their Remote PC after they have suc- 
cessfully connected to a Host UniL Such VDM screen access 
can be prevented by a Host user by mrning the Host Unit's 
ON/OFF switch OFF. 

As previously mentioned, the Keyboard Remote 52 light 
on the front of the Host Unit indicates a remote user is 
accessing the Host Unit. If the light is blinking, it means a 
Remote PC is in the process of initially accessing the Host 
Unit or has been previously blocked by a Host PC user from 
taking over the Host PCs keyboard. If the light is ON. it 



means a remote user has taken over the Host PC's keyboard 
and/or mouse. When a remote user initially attempts to take 
over a Host PC. a brief audible alarm sound is generated 
from a speaker (not shown) within the Host Unit to further 
alert anyone present at the Host Site that the Host Unit's 
keyboard and' or mouse is about to be taken over by a 
Remote PC 

Whole the Keyboard Remote 52 light is flashing, another 
user at the Host PC may depress the Action 55 momentary 
switch on the front panel to prevent a Remote PC from 
taking over the Host PC's keyboard and/or mouse. If the 
Action 55 momentary switch is depressed for this purpose, 
the Keyboard Remote 52 light will continue to flash and the 
remote user wuJ be prevented from taking over the Host 
PC's keyboard and/or mouse until either the Action 55 
momentary switcn is depressed again or the remote user 
disconnects and re -connects at a later time. If the remote 
user should disconnect from the Host Unit while the Key- 
board Remote 52 _ndi cater is flashing, the indicator will turn 
off automatically. When a remote user is blocked from 
accessing a Host Unit's keyboard and/or mouse, they will 
receive an alert message on their VDM screen (connected to 
the Remote PC; during the connection process. Even if a 
Remote user is prevented from accessing the keyboard 
and/or mouse by persons present at the Host Unit, the remote 
user will stall be able to monitor any VDM screen activity on 
the Host PC. Once a aser has taken over a Host keyboard, 
the Keyboard Remote 52 indicator light will remain on. The 
remote user's privilege to continue to use the Host PC's 
keyboard and mouse can be revoked at any time by depress- 
ing the Action 55 momentary switch on the front of the Host 
Unit, which causes the Keyboard Remote indicator light to 
blink unul the remote ascr disconnects from the Host Unit. 
When such an action is taken, the remote user will remain 
locked out until either the Action 55 momentary switch is 
depressed again cr the remote user terminates the connection 
and reconnects at a Later time. 

In cases wnere a Remote User desires access to a Host 
Unit in a manner that would not be readily detectable by 
anyone using the Host PC (hereinafter referred to as a 
"stealth mode'}, the emoodiment of the Host Unit could 
only include AC Power 50 and Setup Mode 54 lights and 
would not include the audibie alarm. In such cases, the 
Remote user would access the Host Unit in a <4 view only" 
mode, as more fully described below in the narrative sup- 
porting FIG. 5B. This ernbodimcnt would be used, for 
example, in cases where an employer desired to remotely, 
discreetly, monitor employee use of an employer's Host PC 
FIG. 3 details the present rear view of the Host Unit A 
variety of alternative interface cables, adapters and connec- 
tors could have been used to connect the Host Unit to the 
Host PC. modem (Modem Linkage mode). Remote PC 
(Direct Line Linkage mode;, and/or another Host Unit on a 
daisy chain. For example, the R J- 12 receptacle presently 
used to connect the Host Unit's serial output to the Host 
PC's serial input could have used a 25 pin female receptacle 
and a parallel interface cable from the Host Unit to one of 
the parallel ports on the Host PC. As a second example, 
standard serial cables and serial receptacles could have been 
used in place of the RJ- 12 receptacles to connect the Host 
Unit to a modern/Remote PC and to connect Host Units 
together on a daisy chain. Such alternative cabling, connec- 
tor and receptacle approaches are known to persons familiar 
with the trade and do not materially affect the functioning of 
the apparatus. 

The rear panel of the Host Unit presently contains the AC 
power receptacles, various RJ-12 data transfer linkage jacks. 
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various video interface receptacles, keyboard interface 
ports, optional mouse interface ports and user replaceable 
fuse with a fuse blown indicator light. A detailed description 
of each item on the back panel going from left to right is as 
follows: 

ON/OFF Switch 60— The OK/OFF power switch 60 is 
used to turn off AC power input into the Host Unit 
Turning this switch ON' or OFF controls only power 
flowing to the internal circuitry of the Host Unit and has 
no effect on AC power Sowing to the Host PC. 

AC Power 61 — The female end of the AC power cord 
used that is normally used by the Host PC to obtain AC 
power is plugged into this receptacle and (he other 
three-prong male end of the cord is plugged into a 
source for AC power such as a public utility wall outlet 
or a battery backup system. This cord would then carry 
AC power into the Host Unit 

AC To PC 62 — One end of the AC power cord suppUed 
with the apparatus is plugged into this receptacle and 
the other end of the power cord is plugged into the AC 
power input of the Host PC, so that the Host PC 
depends on the Host Unit for it's AC power. This 
approach permits the Host Unit to satisfy a request to 
cold-boot the Host PC by temporariiy cutting off AC 
power to the Host PC. The power can be interrupted for 
any suitable time to allow the Host PC to properly 
re- boot for example from approximately 1 to 30 sec- 
onds. In the preferred embodiment this time is approxi- 
mately 15 seconds. 

Fuse 63 — The system employs a user replaceable 5 amp/ 
250 volt fuse on the rear panel with an indicator light 
which lights when the fuse is blown. When the fuse is 
blown power to the Host PC will be terminated. 

Fuse Light 63A — When AC power is applied to the Host 
Unit ana the Fuse 63 is blown, this indicator light will 
be ON. 

VGA Out 64 — For Host PCs with a VGA graphics 
VDAC the 15 pin connector from the end of the Host 
PC's VDM cable is plugged into this receptacle. This 
receptacie permits the signal received from Host PC's 
VDAC through the VGA In 65 receptacie to be passed 
out to the Host PC's VDM. 

VGA In 65 — For Host PCs with a VGA mode VDAC. 
one end of the 15 pin male to male VGA video interface 
cable (supplied as part of the apparatus) is plugged into 
this receptacie and the other end of the cable is plugged 
into the Host PC's VDAC receptacle. This cable inter- 
face permits the Host Unit to capture the video output 
signal from the Host PCs VDAC and pass the signal 
out through the VGA Out 64 receptacie to the Host 
PCs VDM. 

Video Out 66 — For Host PC's with other than a VGA 
graphics card, the 9 pin connector from the end of the 
Host PCs video monitor cable is plugged into this 
receptacle. This receptacie permits the signal received 
from Host PCs VDAC through the Video In 67 recep- 
tacle to be passed out to the Host PCs VDM. 

Video In 67 — For Host PCs with other than VGA mode 
VDACs. the female end of the 9 pin female to male 
video interface cable (supplied as part of the apparatus) 
is plugged into this receptacle and the other male end 
of the cable is plugged into the Host PCs VDAC 
receptacle. This cable interface rxrmits the Host Unit to 
capture the video output signal from the Host PCs 
VDAC and pass the signal out through the Video Out 
66 receptacle to the Host PCs VDM. 
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Keyboard Input From KB 68 — The Host PC's keyboard 
cable is plugged into the Keyboard Input From KB 
receptacle instead of into the PC's Keyboard input 
receptacle. Tots permits the Host Unit to pass or block 
any Ho:t keyboarc input to the Host PC- as required. 

Keyboard Output To PC 69 — One end of the male to male 
keyboard interface cable (supplied as part of the 
apparatus; .s p:ugged into this receptacle and the other 
end ot me cabie js plugged into the Host PC's keyboard 
input receptac:e This receptacle is used by the Host 
Unit to transfer keyboard input nrom either the Remote 
or the Host PC '5 Iceyboard to the Host PC. 

Data la 70 — Qae :ad of a telephone style RJ-12 (6 wire) 
cable ( supplied as part of the apparatus) is plugged into 
this receptacle and the RJ-12 jack on the other end of 
the cab:e ls connected to either the Data Out 71 jack of 
another Host Unit or to either (1) an external, stand 
alone. Hayes compatible modem for a Modem Linkage 
mode or (2) a Remote PC's data transfer interface port 
for a Direct Line T :nkage mode. When a Host Unit is 
connected to mother Host Unit via a daisy chain, at 
least one of me Host Units on a daisy chain must be 
connected to a modem (Modem linkage mode) or 
directly connected to a Remote PC (Direct Line link- 
age mode;. The modem connection can be accom- 
plished by plugg^g me open end of the telephone cable 
into the telephone jack-to-9 pin male adapter plug 
(supplied with the apparatus), and men plugging the 9 
pin maic adapter Jitc the data interface receptacle on 
the modem. If the modem has other than a femaie 9 pin 
receptacle, then gender changers and/or 9 pin to 25 pin 
adapter: 'available for the apparatus) must be used to 
complete the Unit-to- modem connection. The Remote 
PC Direct Line Linkage connection can be accom- 
plished by piuggmg the open end of the telephone cable 
into the telephone jack-x-9 phi female adapter plug 
(supplied with the apparatus), and then plugging the 
female adapter into the data interface receptacle on the 
Remote PC If the Remote PC has other than a male 9 
pin data interface receptacle, then gender changers 
and/or 9 pin to 25 pin adapters (available for the 
apparatus) must be used to complete the Unit-to- 
Rcmote PC connection. 

Data Out 71 — One ena of a telephone style RJ-12 (6 wire) 
cable (supplied as par: of the apparatus) is plugged into 
this receptacle and the other end of the RJ-12 cable is 
plugged into the Data In 70 receptacle of another Host 
Unit If this is the last Host Unit in a daisy chain, no 
cable would be plugged into this receptacle. When a 
Host Unit is connected to another Host Unit, at least 
one of the Host Units on a daisy chain must be 
connected to a modem for the Modem Linkage mode or 
to a Remote PC for the Direct Line Linkage mode (as 
described above for the Data In 70 receptacle); The 
Data In 70 and Data Out 71 receptacles are also used to 
transmit data packets between a selected Host Unit and 
a Remote PC. 

Serial 72 — One end of an RJ-12 cable supplied with the 
apparatus is plugged into this receptacle and the other 
end of the RJ-12 cable is plugged into a serial com- 
munications port on the Host PC using a RJ-12 to serial 
pott adapter plug provided with the apparatus. Data hie 
transfer berween lie Host PC and Remote PC occur 
through tins Senai 72 receptacle. Presently, the appa- 
ratus uses senai data transfers but transfers are also 
possible through the Host PC's parallel port 

Mouse 73 — The Host PC's serial mouse cable is plugged 
into the male Mouse receptacle 73 instead of into the 
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PC's serial port. This permits the Host Unit to pass 
through or block any Host Mouse input to the Host PC, 
as required. 

Aux 74 — Auxiliary devices may be plugged into this 
receptacle, which is presently an RJ-12 jack, and this 
receptacle permits two way communications between 
the device and the Host Unit. Specific uses for this port 
are discussed later. 

On me side of the Host Unit there are eight DIP switches 
(not shown). The left most 6 DIP switches indicate the Host 
Unit's ED number. When these 6 DIP switches are in the 
down position, the Host Unit is connected directly to a 
modem (Modem Linkage mode; or to a Remote PC (Direct 
Line Linkage modej. Otherwise, when the Host Unit is daisy 
chained through other Host Units, each Host Unit on the 
daisy chain must be assigned a unique DIP switch setting 
indicating aa address from 1 to 63 by the user. On this basis, 
only a maximum of 64 Host Units can be daisy chained at 
a Host Site. As noted above, however, the number of DIP 
switches could be increased to allow additional units to be 
daisy chained together. The 6 DIP switch settings presently 
represent binary values reading from left to right. 
Accordingly, if only the left most DIP switch is set to the up 
position, the Host Unit's ID would be 1. If the left most two 
DIP switches were set to the up position, the Host Unit's ID 
would be 3. (i.e. 1—2) and so forth. In order to remotely 
access a Host Unit, the Host Unit ID number must be 
correctly defined on the remote PC's call table, as discussed 
below under the narrative for FIG. 7. 

The seventh and eighth DIP switch are accessible to the 
Host Unit circuitry. The seventh DIP switch is not presently 
used. The eighth DIP switch is presently used for VGA 
VDAC's to indicate whether a monochrome (i.e. DIP switch 
in the UP position; or color (Le. DIP switch in the DOWN 
position) VGA VDM is connected to the VGA OUT 64 
receptacle of the Host Unit 

FIG. 4A through FIG. 4P illustrate general functional 
diagrams of the Host Unit's internal circuitry. A detailed list 
of specific electronic components presently installed in the 
Host Unit is contained in the microfiche appendix, part 1. 
Detailed circuit diagrams defining the specific internal cir- 
cuit Layouts for the present embodiment of the Host Unit is 
also contained in the microfiche appendix, part 2. 

FIG. 4A depicts an overview of the Host Unit's circuitry. 
The unit contains a power supply 100. two microprocessors 
(CPUs) 106, 114. and associated circuitry. 

The Video CPU 114 controls the video circuitry (i.e. 
blocks 110-113 and 115). interface to the Host PC's Data 
Circuitry 116, and interface to me Host PCs Mouse Cir- 
cuitry 117. The Host Data 116 and Mouse Circuitry 117 
interfaces between the Host Unit and Host PC occur using 
the Host PC's serial interface port. However, other Host PC 
data ports, such as a parallel interface port could have been 
chosen for this purpose. The Host Data Circuitry 116 inter- 
face is used to accomplish file transfers between a Remote 
PC and a Host PC. 

The software program source code for the apparatus is set 
forth in the microfiche appendix. Additional features of the 
invention discussed below that could be included in the 
software shown in the appendix by one of skill the art 
include mouse processing capability. Host PC screen history 
recordation, files transfers between a Host PC and Remote 
PC, password lockout protection, temporary password 
processing, training parameter up-loading and down- 
loading, internal modem operation, acoustical coupler 
operation, and AUX port operation. 

The Control CPU 106 controls the Keyboard Circuitry 
101. Host Unit Front Panel Circuitry 102 and Remote Data 
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Circuitry 103 The Keyboard Circuitry 161 passes the Host 
PC's key boar c ^gnais through to the Host PC or alterna- 
tively redirects ail keyboard signals away from the Host 
PC's keyboard :o a Remote PC's keyboard (via the Remote 
Data Circuitry 103 ; when requested by an authorized remote 
user. The fzoz: panel circuitry controls the indicator lights 
and action bucoa .c cared on the Host Unit's front panel (see 
FIG. 2) as -ell as the Host Unit's audible alarm. The Remote 
Data Circuitry 103 permits digital data to flow between the 
Host Unit and a Remote PC and/or other Host Units on a 
daisy -chain. This digital data could be transmitted using 
RS-232 senai conimuaicaucn signals familiar to persons in 
the trade. This digital data could include, for example, video 
display data being transmitted from a Host Unit to a Remote 
PC. Keyboard ujput data transmitted from the Remote PC to 
a Host Unit and modem setup strings. Also, the Control CPU 
106 has access to the Host Unit's fixed serial Dumber 104 
and Non-Voiaule fNV RAM) memory 108. NV RAM 108 is 
used to store the cr.ccal data needed to be saved in cases 
where AC power to the Host Unit is interrupted, such as. for 
example, the passwerdfs; needed to access the Unit. 

The Control CPU 106 and Video CPU 114 communicate 
with each other via a two-way data port 107. 

Presently, the power supply 100 is a linear power supply 
with power transformer, bridge rectifier, filter capacitor, and 
two 7805 5 volt regulators. The power control circuitry 
controls AC power to the Host PC and in the present 
implementation ls comprised of a 5 amp fuse. 5 amp relay 
and associated driver transistor. The driver transistor is 
controlled by a po^er lock circuit 105 that prevents inad- 
vertent arm van cn of this circuit, which would cause AC 
power to me Host PC to be temporarily interrupted. 

The Keyboard Circuitry 101 interfaces to the Host PC and 
it's keyboard. Referring to FIG. 4B. the Host keyboard 
signals 122 are comprised of two primary lines: CLOCK and 
DATA which allow bi-directional communication between 
Che keyboard and the Host PC 120. Symbols used on FIG. 
4B to denote sw itcnes. number of lines, etc. are familiar to 
persons in the trade. When remote access is not c>ccurring to 
a Host Unit ('i.e. a normal local operating mode;, the Host 
PC's keyboard signals arc routed directly to the Host PC's 
keyboard input receptacle as shown in block 121. When in 
remote mode 'i.e. a remote user has taken control of a Host 
PC's keyboard input), the Control CPU 106 causes the 
circuitry 121 to disco nnect the Host PC's keyboard 120 and 
causes the Host PC to receive it's keyboard signals from the 
Control CPU via references 123. 124, 125. The two key- 
board signals. Gock and Data, (nominally at 5 volts, pulled 
high via resistors) go through, an VO circuit 124 and 125 
which separates them into Input and Output lines for each 
signal 126 and shown in more detail at block 127. This 
circuit contains an open collector gate 142 and a pull-up 
tcsister 141 Ca nominal 2.2K value was used). This allows 
the Host Unit to emulate a keyboard signal. References 143 
and 144 represent how the clock and data signals are split 
into input and output lines connected to the control CPU. 

The Mouse circuitry 117 (FIG. 4 A) is further detailed in 
block 131 on FIG. 4B. In local mode, the serial mouse 
signals 132. which could use an RS-232C protocol, are 
passed from the Mouse interface connector (see FIG. 3 at 
reference 73) directly through to the Host Unit's serial 
output (see FIG. 3 at reference 72) to the Host PC's serial 
data port 130, as shown. When in remote mode, the Host 
Unit's Video CPU 114 activates a switch so that only mouse 
input data received from the Remote PC 133 is passed 
through to the Host PC's serial port. In addition, this 
connection also serves another purpose. It allows data files 
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to be transferred between the Host PC and Remote PC- The 
decision as to whether mouse data or data files are being 
transferred is determined by the software operating system 
on the Remote and/or Host PC's. The Host PC treats all 
serial input received as mouse data unless a special software 
program, provided as pan of the apparatus, is activated on 
the Host PC (via Keyboard commands from the Remote PC) 
which will cause the Host PC to treat serial input data as data 
file transfers instead of mouse input data. When processing 
by this software program is complete, the Host PC will treat 
any subsequent serial uipu: as mouse data. 

Host units can be connected together as a daisy-chain 
using a dedicated cable tc interconnect each Host Unit. A 
modem (or primary serial data line; connects to the Host 
Unit Data In receptacle of the Host Unit dumber 00 and the 
Data Out port of this Host Unit can then be connected to the 
Data In receptacle of another Host Unit, and so oq as 
previously described in the narrative for FIG. 1. 

The Control CPU 106 contains an 80C32 microprocessor. 
32K of RAM memory and 32K of EPROM memory, but any 
microprocessor and any amount of memory could be used 
with the invention. The EPROM contains the operating 
system software for this CPU. Also, the Control CPU 106 
has access to an 8 position dip- switch. As discussed above, 
this dip-switch determines the unit's identifi caooa number. 
This number, or address, is used to ailow access to a 
particular Host Unit on a daisy-chain by a Remote PC, and 
addresses may be determined by the user. However. Host 
Unit number 00 is different and expects a Hayes compatible 
modem, or Direct Line Linkage to be connected to the Data 
In port (see FIG. 3 at reference 70). 

As shown in FIG. 4C the Remote Data Circuitry 103 
allows Host Unit access to occur. Data coming from the 
Remote PC 150. slectricaJly passes through the Data In port 
to the Data Out ports of each Host Unit 151. 152. 153 on a 
daisy chain. The Control CPU 151A. 152A. 153A of each 
Host Unit receives any data passing through the daisy-chain 
from the Remote PC 150 on a Receive 155 line. 

Data going from Host Units to a Remote PC is on a 
different transmission line 156 which is separate from the 
Receive 155 line. When no Host Unit on a daisy -chain is 
accessed none of the Host Units are electrically connected to 
the transmission 156 line. However, when a Remote PC 
accesses a Host Unit via in e receive 155 line, that Host Unit 
electrically connects to the transmission 156 line through a 
relay 151B. 152B. 153B to facilitate two way communica- 
tion between the Host Unit and a Remote PC 

AC Power to the Host PC is controlled by a power lock 
circuit 105 (FIG. 4A). This circuit insures that an intentional 
data transfer occurs before the power control circuitry 100 
will briefly interrupt AC power to the Host PC. This nock" 
circuitry requires that not only a specific series of values be 
written to it but also at specific port addresses, and a 
separate bit value must be correct at the time of writing, 
before the Host Unit will permit AC power to the Host PC 
to be interrupted. This power lock circuit, as well as the 
video processing circuitry discussed below, both utilize a 
Cyclic Redundancy Check (CRC) function familiar to per- 
son of skill in the art for processing. 

As shown in FIG. 4D. CRC is a common process used for 
generating pseudo-random numbers and reducing long 
streams of data to a smaller check sum quantity (1. 2. or 
more bytes). CRC is typically used for random number 
generation, bit stream identification and bit stream error 
detection. 

The CRC process is based on shifting the parity, or single 
bit sum, of an input data signal 185 and selected bits 178. 
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179. 181 of a shift register output 177. Each time the shift 
register 172 is clocked 171. a new bit 170 is shifted into the 
shift register. EXCLUSIVE OR gates 180. 182. 184 generate 
the parity signal. After 3 docks, the new value 177 will have 
no apparent relation :o the previous value. If the input bit 
185 is hara- wired to plus (or a logical 1). a loag series of 
pseudo-random values can be generated. Rather than hard- 
wiring thi: :opu: 185 gaie 184 would normally be omitted 
and signal 183 would be connected to 170. The series 
generated will repeat every N clock cycles where N has a 
theoretical maximum of 256 for an 8 bit shift register and 
65 J36 foe a 16 bit shift register. If a data stream is present 
185. this will modify the pseudo- random series and produce 
a unique vaiue at 177 wruch can be used to identify the data 
stream. Note that the partcular bits 173. 174. 176 of the shift 
register output 174 selected for parity generation determines 
the pseudo-random series generated. That is. connections 
178 and 179 can be connected to different bits of 177, such 
as the output bit referenced at 175 and/or more bits can be 
added with more EXCLUSIVE OR gates and the numbers: 
generated will be different. 

FIG. 4E shows a diagram of the power lock circuitry. The 
CRC generator 213 uses an 8 bit shift register and is similar 
to FIG. 4D with the data input 185 omitted and a clear input 
212 is provided. This clear input will set the CRC value to 
zero. Power to -he Host PC is terminated when bit latch 
output 222 is ON. To set this bit latch output 222. the Control 
CPU (in the present implementation.) generates a write 
pulse to the bit latch 221 ~oen the digital signal 223 is a one 
(logical high;. This signal 223 is a one (logical high) only 
when the CRC value 196 is compared via the compare 
circuitry 198 anc is ecuai to the value 128 (hexadecimal 80) 
which is hard- wired 197 x> this value. Signal 202 will clock 
the CRC generator 213 only when the compare output signal 
190 is a one logical high). Otherwise signal 202 will instead 
set the CRC value 196 :o zero. This is accomplished by logic 
gates 200. 204. 265. When a CRC output 1*96 is compared 
with data input 194 via compare circuit 195. and is equal 
then output 190 will be a one (logical high). Assuming the 
CRC value 196 is zero, then approximately 250 dock pulses 
211 occur before the CRC value 196 will reach 128 (80 
hexadecimal) during which time the CRC generator 213 will 
have produced approximately 250 unique CRC values 196. 
To produce these dock pulses 211 the value 194 must be 
equal to the current CRC vaiue 196 for each write pulse 202. 
This data byte input 194 is composed of three sets of signals 
191. 192, 193. The address lines 193 makes this port 194 
appear as 8 output ports :o the Control CPU 106 (FIG. 4A). 
Thus, the Control CPU must correctly set up the lock bit 
191. and write (via pulsing at reference 202) a correct value 
192 to the correct port 193 with the combination of these 
signals being equal to the current CRC 196 to clock 211 the 
CRC generator and get the next CRC vaiue. This continues 
until the CRC value becomes 128 (80 hexaaecimal) and then 
the Control CPU pulses 220. The choice of 191. 192. 192 
ensures that the Host PC's AC power will not be interrupted 
inadvertently in the event of erroneous processing by the 
Control CPU 

The above circuit is employed in the most preferred 
embodiment of the present invention to ensure that power to 
me Host PC will not be interrupted unless commanded by a 
user. However, if such precautions are not warranted, a 
simpler power management circuit could be employed to. 
for example, reduce me overall cost of the system. This 
circuit could, for example, only require that the control CPU 
106 receive a power interrupt command byte from the 
remote user. Other examples of less complex power man- 



agement circuits will be readiiy apparent to those of skill in 
the art in light of the above discussion. 

The Control CPU 106 has access to a serial number device 
104. This provides a unique hardware serial number for the 
unit. The preferred eiabodiraenr of the present invention 
uses a DAJLLAS DS2401 part, which comes pre- 
programmed with a unique serial number. Of course, other 
suitable means could be smpioyed to retain the hardware 
serial number for each Host Unit Also, the Host Unit 
includes 2K of non-voianie RAM 108 for storage of the 
unit's password and video timing and CRC information 
peculiar to the Host PC's video hardware configuration, 
which are determined during a Host Unit training process 
discussed below in connection with FIGS. 6A to 6D. 

In the preferred embodiment, the Video CPU 114 contains 
an 80C32 microprocessor, two banks of 32K by 8 bits of 
RAM memory (totalling 6*K ; and32K at EPROM memory. 
This microprocessor, as well as the control microprocessor 
106 discussed above, could be replaced by any suitable 
microprocessor (for example an 80286. 80386. 80486. 
68000, 68010. etc.; and memory. The EPROM contains the 
operating system software for this CPU. An RS-232C serial 
port 116 is provided for rile [ransfers or serial mouse data to 
the Host PC 

The portions of the Host Unit which deal with video 
processing employ a combined hardware / software 
approach. In this regard, discrete logic circuitry does some 
of the video process mg and a microprocessor and associated 
operating software performs the remainder of the video 
processing. In the preferred ernr^xliment. this was done to 
preserve flexibility in the video processing techniques. As 
will be readily apparent to -hose of skill in the art. other 
embodiments of the invention may dedicate more of this 
processing to discrete circuitry, to lessen demands piaced on 
the processing software to increase processing performance, 
or more of this processing to software or hardware to 
enhance flexibility. 

The Control CPU 106 and the Video CPU 114 commu- 
nicate through a two-way communication port 107. As 
shown in FIG. 4F. the Conuol CPU 106 checks the write 
status 232 to see if the latch 234 is empty. If it is empty, the 
CPU presents a value 230 and toggles the write line 231. 
This will set the bit latch 236 and the status 232 will indicate 
that the latch 234 is full. The Video CPU 114 can then poll 
the read status 232 and. if :t is set. read the value 233 by 
pulsing 235. which will reset the read status 232. The Video 
CPU 114 checks the write status 240 to sec if the latch 24S 
is empty. If it is empty, then the Video CPU 114 presents a 
value 246 and toggles the write line 244. This win set the bit 
latch 243 and the status 240 will indicate that the latch 245 
is fuiL The Control CPU 106 can then poll the read status 
240 and. if it is set. read the value 242 by pulsing 241. which 
will reset the read status 240. The status signals 232 and 240 
are both referenced as read and write status and their 
function depends on which CPU is polling the status signal. 

As shown in FIG. 4A. the Video CPU 114 programs the 
video circuits 110. 112. 113 after which video signals, 
including video raster signals, corning from the Host PC 
VDAC (discussed in more detail in FIG. 4G) are processed 
by the Video Signal Input Circuitry 11° the Video CPU 
111. The resulting video data is written to the Video Output 
Buffer 115. In the preferred embodiment, this buffer is 32K 
by 16 bits, which is enough memory to hold one screen of 
800 by 600 digitized graphics or more than one screen of 
text data. The Video Processor 111 writes to this Video 
Output Buffer 115. so that the data written to the buffer can 
be read by the Video CPU 114. 



23 

The video input enters from the Host PC's VDAC 
through a video interface cable which Is presently either a 
DB 9 pin receptacle (with TTL video signals) or a DB 15 pin 
receptacle fwith analog video signals) located oq the rear 
panei of the Host Unit i'see FIG. 3 at references 65 or 67). 
For both of :hese receptacles, the hori2ontai and vertical 
syncs are TTL signals When these video signals enter the 
Video Sigrai Input Circuitry 110. the circuitry selects sync 
polarity. TTL zc analog mode, and a particular color signal. 
This signal :s passed tc the Video Processor 111. 

Analog VGA disc-lay monitors can be either color or 
monochrome As previously mentioned the eighth DIP 
switch in the Host Unit is presently used to indicate whether 
a monochrome (It. DIP switch in the UP position) or color 
(Le. DIP switch In rhe DOWN position) VGA VDM is 
connected to the VGA OUT 64 receptacle of the Host Unit. 

Analog fVC-A, monochrome monitors generally display 
only the green signal When the PC is reset, the VDAC will 
interrogate the three monitor identification signals coming 
from the VDM tc determine the type of monitor that is 
connected (i.e monochrome or color). If a monochrome 
monitor is detected, lie VDaC will add together the red, 
green, and blue coior signais and output this one combined 
signal to ail three coior gun outputs. This gray scale sum- 
ming is designed so that the same amount of brigntness will 
be displayed ld monochrome as would be displayed in color. 

The ±xee monitor .den till cation signais appear on pins 4. 
11. and 12 of the monitor's DB 15 video connector. The Host 
Unit currently hardwires these signais so as to appear to the 
VDAC that a color monitor is always present (i.e. pins 4 and 
11 grounded, pin 12 open;, regardless if a monochrome or 
color VDM .s connected to the VGA OUT 64 receptacle of 
the Host Unit. For simplicity, this enhancement to the Host 
Unit's circuitry is not rejected in the schematics contained 
in the microfiche appendix, part 2. 

If a color monitor is connected to the Host Unit, the red 
green, and blue signais simply pass through, and arc dis- 
played in coior. When a monochrome display is attached, tne 
Host Unit will apply gray scale summing and output this 
sum on the red. green, and biue signals going to the display 
monitor. This surnrning is not reflected in the microfiche 
appendix. The formula for gray scale sunirning is: 30% 
red+59^ green+i;^ biue. This gray scaie summing is 
independent of the Hos: Unit's video processing and affects 
only the video output to the monochrome monitor. The Host 
Unit could determine whether or not to apply this gray scale 
summing by examining the identification signals coming 
from the monitor, but in the current implementation, position 
S of the Dip Switch is used to indicate the type of VDM 
connected to the Host Unit. 

Forcing the Host PC's VDAC to believe a coior VDM is 
always connected permits the Host Unit and remote users, 
to have access to color information, regardless of the moni- 
tor type connected to the Host PC via the Host Unit In other 
words, this approach permits a remote user to view 3 Host 
PC's VDaC in coior even in cases where a monochrome 
VDM is connected to the Host Unit. In addition, because 
Host Unit video output signals are buffered, the Host Unit 
need not have a VDM connected to the Host Unit. In cases 
where a remote user has a monochrome VDM connected to 
their Remote PC. the TVLINK.EXE software program 
(discussed later) will ignore any color attributes sent by the 
Host Unit for display purposes. 

An overview of the color signal selection circuitry of the 
Video Signal Input Circuitry 110 is found in FIG. 4G. Video 
Select Latch 257 controls which color signal is selected. 
This latch is set by the Video CPU 114. Latch signals 256 
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control the muitip lexer in the Video Signal Select 264 which 
sciccts, coc of Che TTL signals red 260. green 261, blue 262. 
or intensity 263. or the converted analog signal 2S4 and 
presents this signal at 265 which will be clocked into the bit 
latch 267 for each pixel clock 266 and appear at the Bit 
Latch output 268. The VGA Color Select 255 signal causes 
the Analog to TTL Circuitry 253 to select a particular analog 
signal 'i.e. red 250. green 251. or blue) 252. to be converted 
to a TTL output 254. 

The most preferred embodiment of the invention pres- 
ently provides for only one color signal to be processed per 
video raster scan cycle. Therefore, multiple scan cycles are 
required to derive color text information. Since approxi- 
mately 60 scan cycles occur per second, color signals can be 
processed and decoded to achieve reasonable throughput of 
color text data to a Remote PC. Future embodiments could 
add circuitry and/or software to allow simultaneous process- 
ing of all color signals by. for example, pre-digitizing each 
color signal (using shift registers and latches, as described in 
FIG. 4K) and storing this data into a separate memory 
storage area before passing this information to the Video 
Processor 111 circuitry. This alternative approach would 
permit text and graphics color attributes to be more precise 
by avoiding potential discrepancies caused by processing 
multiple scan cycles where VDAC screen data changes 
between each cycle. 

As shown in FIG. 4H. analog color signals vary from zero 
volts 272 for black 278 to approximately 0.7 volts 270 (into 
a 75 ohm load) for white 275. Light gray 276 and dark gray 
277 are between these two limits. To be processed by the 
present video circuitry, this analog signal needs to be con- 
verted to a digital TTL signal To accomplish this, a thresh- 
old levei is set 271 so that color levels above this level 274. 
275. 276 are converted to a LOGICAL i (high) signal 281. 
Color levels below the threshold such as 273. 277. 278. etc. 
will be convened to a LOGICAL 0 (low). The resulting 
VGA Video output signal 280 is depicted beginning at 
reference point 280 and is the output of the circuit as shown 
at reference point 297. Using mis present approach, a 
foreground color of dark gray 277 on a background color of 
black 278 wijj not be discerned by the circuitry. Neither will 
a combinations of white 275 and light gray 276. Also, 
although white, gray, and black 275. 276. 277. 278 are 
referenced, the actual cclcr depends on the color signal 
selected and will be either red. green, or blue. The analog 
color signals 290. 291. 292 are selected by an Analog Signal 
Select multiplexer 293 and presented to the positive input 
294 of a comparator 296. The minus input 295 is fixed at a 
threshold value 271. The output of the circuit 297 is a TTL 
signal as illustrated beginning at reference point 280. The 
circuit could use. for example, an Analog Devices part 
AD9696 comparator. 

The Video Processor handles both digitizing graphics and 
text mode character recognition. For processing purpose a 
"pixel** is equivalent to a "logical bit". 

As shown in FIG. 41 block 300 depicts a VDM displaying 
six characters: "A". t *B", "C\ **D" and two characters from 
the extended ASCII character set. namely a solid block and 
a cross. As shown on FIG. 4J, the total video signal is 
composed of several parts: Vertical sync 340. horizontal 
sync 343. and color signai(s) 350 (illustrated as only one 
signal). Whereas color VDAC uses red. green, and blue 
signals, monochrome VDAC often use green and intensity 
signals only. As shown in FIG. 41. the visible portion of the 
VDM 302. where text and graphics appear, is only a subset 
of the total video signal. Slock 310 shows a close-up view 
of the upper, top left corner of the entire VDM 301 which 
includes pan of the left- :op corner of the visible VDM 302. 
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As shown in FIG 4J. the vertical sync signal 340 com- 
mands the moaner to go co the top of the screen 301. 313 and 
start scanning downward to the bottom of the screen. 304. 
The horizontal 7/nc signal 343 commands the monitor to go 
to the left side of ±c screen 305. 325 and scan to the right 
side of the screen 303. The color signals create visible light 
on the VDM's screen jn the form of text and/or graphics 302. 
Although 314 decicis the first visible horizontal scan line, 
there arc horizontal scan lines above (see 301. 313. and 352) 
the first visible scan line 314. As shown in FIG. 4J. reference 
345 illustrates tne first visible horizontal scan line and 
reference 34% illustrates the last visible horizontal scan line. 
References 330 and 333 expands a single horizontal scan 
line 346. Although ±e first scan line 314 and the last scan 
line 315 for a character row represents 16 horizontal scan 
lines (typicai for VGA text mode), some older moDOchrome 
VDAC only generate & horizontal scan lines as shown at 
reference 353 berweea references 345 and 346. Reference 
334 shows the first character row's horizontal scan line 316 
over the ~C character on FIG- 4L Similarly, reference 336 
represents scan Line 316 over the "D". Reference 338 is the 
same scan line over the SOth character (not shown on FIG. 
41). Reference 347 represents the next horizontal scan line at 
317. The horizontal sync pulse 330 starts the horizontal scan 
line 316. There is a delay 335, 32S. 305 before the first 
visible horizontal pixel 324. 

References 324. 322. 321. and 320 position the first pixel 
of each character of a given row. The 9th position 323 which 
is preset for VGA. Hercules, and other VDAC (not for early 
monochrome VDaC which is % by 8) is not talcen into 
account. The pixel clock, signal only captures the first 8 
pixels of the character so that the digitized video ignores this 
pixel 323. 

The first horizontal scan Lice (non-visible) 344 is depicted 
at reference 312 on FIG. 41. The last visible scan line 348 
completes a VDM's screen. Presently. VGA text mode has 
350 visible horizontal scan lines. VGA graphics mode 
(640x480) has 480 scan lines, hi-res mode (800 by 600) has 
600 scan lines, but the present system is capable of operating 
with any number of differing graphics modes and display 
lines. 

After the horizontal sync pulse 330. and die left margin 
delay 305. 325. 335. Ac visible video occurs as illustrated at 
reference 337. A scan line for the first two characters is 
shown in FIG. 4K beginning at reference 360. The preferred 
embodiment of the Video Processor uses a 16 bit shift 
register and a 16 bit Latch. FIG. 4K. however, only depicts 
an S bit latch and shirt register for illustration purposes. 

As an example of the process of digitizing video 
characters, assume each character is 8 pixels wide, as 
illustrated beginning at reference 365 and ending at refer- 
ence 370. When digitized, these eight pixel values make up 
the eight bits of a byte used for further processing. After the 
gth pixel 370. there is a 9th unused pixel labeled "X" (shown 
at reference 375). This 9th pixel occurs for VGA VDAC as 
well as some monochrome VDAC. Some VDAC do not 
have this pixel so that the last pixel of one character 370 is 
immediately followed bv the first pixel of the next character 
373. 

Reference 361 shows an actual wave form from a hori- 
zontal scan line illustrated on the graph 390. as the last 
horizontal row at the base of the characters and **M M 
ending with the pixel referenced at 394. Reference 364 
shows the bottom line of the 4< L". reference 371 shows the 
left leg of the **M*\ and reference 374 shows the right leg of 
the "M". 

The video pixel data 365 input 391 to the shift register 393 
will appear at the first shift register output bit 395 after a 
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clock pulse at 392. After 7 more clock pulses, the video pixel 
data 365 appears at the last shift register output bit 399. 
Thus, to digitize a character, each pixel data bit (e.g. 365) is 
shifted into a shift register 393 from Video signal input 391 
via a Pixel Clock 362. 392. After the 8th pixel 370 is shifted 
into the shift register, the data is transferred into the Latch 
398 via the Latch Clock 363. 372 at 396. After the data is 
latched, the output of the Latch 398 indicated at reference 
397 is then stored into the Video Output Buffer 115 (FIG. 
4A) for later retrieval by the Video CPU 114 (see FIG. 4A). 
For VDACs where the last pixel of one character 370 is 
followed immediately by the first pixel of the next character 
373. then Latch Clock 372 occurs coincident with the first 
pixel of the next character. 

Once in the Video Output Buffer 115 (FIG. 4A). the 
digitized video data can be transferred, through the Control 
CPU 106 (FIG. 4A) and out the Remote Data Circuitry 103 
(FIG. 4A) to a Remote PC 2 (FIG. 1). which can then be 
directly displayed in graphics mode. Although presently 
supported, this transfer requires sixteen bytes per character 
which slows down the transfer of screen data to a Remote 
PC. In cases where a Host PC VDAC is in a text mode, 
screen transmission times can be cut dramatically by con- 
verting a character* s 16 byte packet into a one byte character 
code, such as used by the ASCII coding scheme, and 
transmitting only the one byte code instead. Depending on 
the particular VDAC. characters can use 8. 9, 14. or 16 
horizontal scan lines or byte packets, all of which are 
handled by the Host Unit's circuitry. For illustration 
purposes. 16 horizontal scan lines (presently used by VGA 
VDAC) has been selected for further discussion. 

The conversion from pixel data to characters requires 
some kind of character recognition of which several 
approaches are possible. The first approach is to take the 
digitized video and search a look-up table for a match of this 
character's 16 byte packet, which represents the 
re -organized pixel data which corresponds to a single char- 
acter. The relative position in this table wouid then yield the 
character code, such as used by the ASCII coding scheme, 
associated with the desired character. This method is less 
preferred because the particular shapes of characters vary 
among different VDACs and the look up table would require 
excessive storage of character set mappings. Furthermore, 
the table would have to be updated to handle new character 
sets or character format changes. 

A second approach wouid be to process the digitized 
video data by certain algorithms which directly infer (or 
recognize) the character's identity such as those typically 
used by OCR (optical character recognition) software famil- 
iar to persons in the trade. This approach is less preferred 
because it is computation intensive requiring too much 
processing on the part of the Video CPU 114 (FIG. 4A). 
which slows video screen access by a Remote PC and 
degrades throughput to a Remote PC- 

A third approach, which is employed in the most preferred 
embodiment of the invention, uses CRC methods for char- 
acter recognition. Under this approach, the digitized video is 
converted directly to CRC values by hardware circuitry, 
after which these values are written to the video output 
buffer. 

To convert a 16 byte packet to a unique CRC value, the 
packet data is serialized (dropping the ninth pixel, if present; 
and the resulting bit stream is input to the CRC generator. 
FIG. 4L illustrates this process. Each horizontal scan line for 
a particular character 410. 411. and so forth down to 417. is 
processed sequentially as shown beginning at reference 400. 
It can be seen that the tip of the "A" (see 412) is followed 
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immediately by the top line of the "B" as shown within 
block 407 In the mosi preferred embodiment, the CRC 
general or is more correctly called a CRC processor, in that 
Intermediate CRC values generated can be saved and then 
later restored to process the next horizontal scan line. First 
the CRC shift register value is set to zero. Then the first line 
of the cell containing the "A" 410. 401 is processed, after 
whici che intermediate CRC value is saved. Then the CRC 
shift register value :s again cleared and the first line of the 
ceil containing the "B" (see 407; is processed, and so on. 
After the entire horizontal scan line 410 is processed, scan 
line 411 begins. First, the previously saved intermediate 
CRC value for the ceil containing the '* A" is loaded into the 
CRC shin register. Then. 402 is processed after which again 
the intermediate CRC value is saved, and so on. Thus, when 
processing 30 column text data, there will be 80 intermediate 
CRC values saved for each scan line. This allows the CRC 
generator to "see" 16 contiguous bytes for each character. 
After the last horizontal line 417 for the "A" is processed, 
the resulting CRC value is the CRC for the character and is 
stored into me Video Output Buffer 115 (FIG. 4A) and so on 
for the remaining characters. Later the Video CPU 114 (FIG. 
4A; reads nhese CRC values and searches a look-up table of 
character CRC values for a match. A special initial training 
process, discussed in more detail below, generates this cable 
of CRC vaiues. w'mch reflect the actual VDAC character- 
istics of me Host PC. This process translates the actual 
character formats used by a given VDAC to a unique CRC 
for each different character. 

Another approach to convert pixel information to char- 
acter format would be to store all 16 horizontal lines of 
di^dzed data (16 by 80 bytes) and then process each 
character in serial order 400. Two banks of 16 by 80 byte 
memory would be required so that new digitized data could 
be stored while previously stored data is being converted to 
CRC values. This approach uses software instead of hard- 
ware to do the processing, but otherwise is suitable for use 
in the present invention. 

The Host Unit' 5 circuits could be enhanced to include a 
memory translation circuit between the Video Processor 111 
(FIG. 4A; and the Video Output Buffer 115 (FIG. 4A) where 
the CRC value output from 111 (FIG. 4A) would form the 
address whicn accessed a memory byte containing the 
character code, such as used by the ASCII coding scheme, 
for the character and store this code into the Video Output 
Buffer 115 (FIG. 4A>. The Video CPU 114 (FIG. 4A) would 
then read the character codes from the video output buffer. 

FIG. 4M gives an overview of the current implementation 
of the Video Processor 111 (FIG. 4A). The CRC generator 
is composed of a 16 Bit Shift Register 439 (rather than 8 bits 
as shown in FIG. 4D) and a 9 bit Parity Generator 423 
(rather than EXCLUSIVE OR gates as shown in FIG. 4D). 
The output of che Parity Generator 421 is input to the Shift 
Register 439. The particular output bits of the Shift Register 
439 which arc summed with the Video Input 420 is con- 
trolled by a Feedback Select circuit 425 (8 dual input AND 
gates). The first 7 least significant bits along with the most 
significant bit of the shift register output 426 is logically 
ANDed with S 14 enable" bits 428 from a CRC Config Latch 
429. This iatca is set by the Video CPU 114 (FIG. 4A> and 
configures which of these 8 shift register output bits 426 are 
input to the parity generator. This Latch 429 is used to 
configure the CRC generator to produce unique CRC values 
for the video character set to be recognized. If this value 428 
is set to zero, then ail 8 bits in 424 will also be zero and the 
parity output 421 will directly reflect the Video Input signal 
420. It is by this means that the Video Input 420 is digitized. 
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with the latched data 442 being stored directly into the Video 
Buffer 444. without being changed by the CRC generator. 

The Pixel Clock. 422 clocks video pixel data into the CRC 
shift register 439. As shown In block 454. the nrst pixel of 
the second character 453 directly follows the last pixel of the 
first character 452. The 9th unused bit (referred to earlier) 
does not appear on f Jie graph on FIG. 4M as it does not have 
an associated pixel clock. 

The Temporary CRC buffer 438 is cleared by Clear line 
433 being puised by the vertical sync signal. The Shift 
Register 439 is cleared to zero via 431. Then. 8 Pixel Clocks 
422 occur coinciding with the 8 pixels starting with 451. 
After the 8th pixel 452 is processed, the intermediate CRC 
value now appearing at the Larch input 427 is latched via the 
Latch clock 440. The shift register 439 is again cleared via 
431 and the next character is processed starting with pixel 
453. While this next character is being processed, the value 
previously latched 441, 442 is written to a temporary CRC 
buffer 438 by pulsing the write line 443. This continues until 
all characters are processed for this horizontal scan line and 
the Temporary CRC Buffer 438 contains 80 intermediate 
CRC values. Then, the next horizontal scan line begins. 
Before pixel 450 is processed, the previously saved inter- 
mediate CRC value in the Temporary CRC Buffer 438 is 
loaded into the Shift Register 439 via the read line 437. 432. 
mid 430. After the 8th pixel is processed, the new interme- 
diate CRC value is again latched 441 and stored into the 
Temporary CRC Buffer 438, as described above. 

This process continues until a horizontal scan line 455 
begins. For this scan, intermediare CRC values are restored 
as before, but after pixel 456 occurs, the latched CRC value 
at 442 is the final CRC value identifying the character 
processed ("A" in me example) and is stored into the video 
buffer 444 via the write line 445. This is true for the 
remaining characters on this scan line 455. Tae next scan 
line begins the next row of characters and the process 
starting at 451 repeats until all 25 (for an 80 by 25 video text 
mode) rows of characters are converted and ail 2000 char- 
acter CRC values are stored into the Video (output) Buffer 
444. which is the same as the Video Output Buffer 115 in 
FIG. 4A. 

A possible alter native to storing CRC values in the Video 
Buffer 444 would be to convert the CRC values before 
storage into the Video Buffer 444. This could be accom- 
plished by inserting a memory circuit before the video 
buffer, which would function as a look up tabic whereby the 
16 bit CRC value referenced at 442 will form the memory 
address. The resulting 16 bit output of this memory would 
contain the character relating to a given CRC. The Video 
CPU would initialize this memory with CRC information. 
For invalid CRCs Ihe 16 bit value is set to zeros. For normal 
character CRCs the low byte is set to the ASCH code of the 
character and the nigh byte would be set to zero. For 
highlighted (inverse) character CRCs the high byte would be 
set to the ASCII code and the low byte would be set to zero. 
This approach would permit immediate translafion of CRCs 
to characters and would improve Host Unit performance. 

As shown in F[G. 4N. the video pixel duration as gener- 
ated by monographic VDACs is about 65 nanoseconds, and 
for VGA VDACs it is about 30 nanoseconds. The Video time 
line 458 shows three video pixels: a white, a black, and 
another white pixel. VGA video requires a fast Pixel Clock 
459. The slanted lines indicated by 461 shows jitter pro- 
duced when any two asynchronous signals interact (the 
video signal and the Host Unit's video clock). Using 90 
megahertz as the base clock rate for pixel clock generation 
(in the current implementation) this jitter is about 11 nano- 
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the rising edge of me pixel clock near the end of the video 
pixel as shcrs-'D *£ reference 460. a resoluuon of 5 nanosec- 
onds was incorporates into the design. Thus, if reference 467 
shows the purl ci>ck at 460. the circuitry can reposition the 
pixel clock u 463 or 5 nanoseconds later, if needed. This 
wouid make ;ne ?ase :ioc£ appear to be between 180 to 200 
megahertz. Of :->jr:e :icce the base dock in the current 
Lmpleracntauorj .s SO megahertz, or a period of 11 
nanoseconcc. arc me iciav is 5 nanoseconds, the position of 
the pixel dock foiows -he pattern 0 ns. 5 nanoseconds. 11 
ns. 16 ns. 22 as etc That is, it is centered around a 190 
megahertz resoluuon. and it is a practical solution to achieve 
the desired recLl: ■*;.* :c clock in a stable pixel data bit). 

To expia;a ;icsr. ±c rising edge of the Horizontal Sync 
462 pulse synchronizes the pixel clock. Jitter is inherent in 
that it cannot be inown in advance what the phase of the 
base dock will be at this time. In fact, the phase of this clock 
will be coannuousiy changing in respect to each new 
horizontal scan. To illustrate this. 463 and 464 show the base 
clock in differ err. phases. Note that the rising edges of the 
base clock 465 and 466 occurs at different times after the 
rising edge of the sync pulse 462. Since fee Pixel Clock 460 
is derived from this sync signal and the base clock, the video 
pixels 458 inner.: the ioer as shown at 461. The start and 
end of each pixel wil fluctuate within the area shown at 
reference 461 

The current _mp:e mentation of the Pixel Timing Circuit 
112 (FIG. 4a ; is shown J3 ETC 40. Presently, this circuit is 
a 4K by 8 bit 20 zano second RAM memory. The Video CPU 
114 (FIG. 4A; programs this memory via the data in 470. 
and the wrae line 477 This memory is addressed by the 
output 483 of a 12 bit counter 484. First, this counter 484 is 
cleared via reference 485 and. after each write pulse, incre- 
ments the address counter via reference 486 (this connection 
is not shown on :he figure "hen processing video, the read 
line 478 is enabled. The horizontal sync signal clears the 
address counter the clear line 485. The output byte of the 
RAM memory 471 is split into two 4 bit nibbles 472 and 479 
and are loaded into two 4 Bit Shift Registers 473A and 480. 
A 90 megahertz Oscillator 489 clocks these shift registers 
and. via the clock signal 488 and the Divide By 4 circuit 487, 
loads the rwo nibbles into the shift registers every fourth 
clock cycle and ids n increments the 12 Bit address Counter 
484. The rwo smft registers then output each 4 bit nibble one 
bit at a time at references 473B and 481 to generate the Pixel 
Clock signal 476. The output of the Shift Register 481 is 
delayed 5 nanoseconds via a 5 ns Delay 482 (presently a 
D AULAS DS 1 COO- 25 j and the two signals 473B and 474 are 
logically ORed via reference 475 to produce the Pixel Clock 
476. Thus, the pixel clock generated can be aligned to the 90 
megahertz clock rate every 11 nanoseconds or delayed 5 
nanoseconds. Only one bit of one nibble at a time can 
become the pixel clock. Other means which could be 
employed include using a phase lock loop (PLL) or other 
precision deiay elements to generate the pixel clock. 

The poianry of the vertical and horizontal sync signals 
change, as well as their relationship to each other, depending 
on the VDAC in use and the particular video mode (e.g. text 
or graphics modes). As shown in FIG. 4R, references 490 
and 491 show example Vertical Synchronization (Sync) 490 
and Horizontal Synchronization (Sync) 491 signals. But, 
depending on the video mode or VDAC. the Horizontal 
Sync 491 may appear as shown at reference 492 and the 
Vertical Sync signal 490 may appear as shown at reference 
501. To accommodate this, rwo exclusive OR gates refer- 
enced as 498 and 500 are used so that the sync signals which 
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drive the video circuitry arc always negative polarity at 
references 497 and 499 The Video CPU 114 (FIG. 4A) sets 
the polarity bits referenced at 494 and 496 to accomplish 
negative polanry. 

The phase relationship of the vertical and horizontal sync 
signals also vary per VDAC as shown at references 501 and 
503, Both rising edges occur at the same time. Referring to 
references 503 and 504. notice that the rising edge of 504 
occurs after the rising edge of 503 as compared with the 
phase relationships shown at references 501 and 502. To 
normalize this to a consistent phase relationship, a flip-flop 
is used as shown at block 508. The VSYNCTemp signal 499 
is used to clear the flip- Sop as shown at reference 510 and 
the rising edge of the HSYNC Out signal 497 which is 
connected ro ihe clock input 507 and sets the output 509 to 
a one (logical high) via data input 506 (hard-wired to +5 
volts). The VSYNC Out signal is shown as reference 505. 

The Horizontal Control Circuitry 113 (FIG. 4A) imple- 
ments the narrative and timing diagram for FIG. 4J and FIG. 
4M. Referring :o FIG. 4J. after the vertical sync begins a 
new screen at references 340 and 351. this circuitry skips me 
non-visible horizontal sync signals referenced at 352. then 
repeats the cycle of initializing the CRC shift register 439 
value to zero 431. for each character of the first horizontal 
scan line, saving and restoring intermediate CRC values via 
43S for the middle character scan lines, and writing the final 
CRC values for each character row to the Video output 
Buffer 444 (115 FIG. 4A). 

The Host Unit contains two microprocessors (i.e. CPUs) 
106. 114 each with their own independent software operat- 
ing system, FIGS. 5A through 51 provide an overview of 
these software operating systems. Source program code 
written in 8032 assembly language for the Video CPU 114 
is contained in the microfiche appendix, part 5. Source 
program code also written in 8032 assembly language for 
the Control CPU 106 is contained in the microfiche 
appendix, pan 5. As lcnown to persons famili ar to the trade, 
operating system software, such as that used for the Control 
and Video CPUs, is primarily event or interrupt driven and 
docs not follow the linear logic flow typical of most appli- 
cation software. 

The present embodiment includes two CPUs primarily to 
spread the processing workload so as to give a remote user 
the impression (to the extent possible) that they are actually 
sitting at the Host Unit. Decoding the high speed video 
signal of the Host Unit's VDAC presently requires almost all 
of the processing speed of a typical high speed micropro- 
cessor. Adding additional processing requirements to the 
CPU responsible for decoding video signals may prevent the 
CPU from keeping up with the data output of a VDAC. 
Hence, a second CPU was added to the present design of the 
Host Unit. As noted above, however, with faster micropro- 
cessor technology, a single CPU could be used. 

FIG. 5A represents an overview of the Control CPU 106 
(FIG. 4A) operating software. When power is first applied to 
the Host Unit, the CPU begins executing the initialization 
routine 600. This routine docs the nominal housekeeping 
such as setting certain variables to default values, clearing 
counters, setting up interrupt parameters. After this, the dip 
switches are accessed to determine the Host Unit's identi- 
fication number. Then, non-volatile ram is accessed 108 
(FIG. 4A) for the Host Unit's access password, default 
modem data and to check if the Host Unit is setup to process 
video (via training discussed below in connection with FIG. 

If the Host Unit is ready to process video data, a video- 
ready command is sent to the Video CPU (via 107 FIG. 4A) 
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to indicate that video processing can commence. The ini- 
tialize rouune 6tK) then sets up the Remote Data Circuitry's 
serial daia port 103 (TIG. 4A). If the Host Unit's identifi- 
cation aurac-cr is zero, the Host Unit's data pon is discon- 
nected frcrc the chaining port, the CPU's serial port transmit 
and recer.- signals arc directly connected to the host data 
port, and a modem which is expected to be connected to the 
remote data por.. :s .rutiaiized. In a case where a Remote PC 
is direr.iv connected :o a Host Site via a Direct Line 
Linkage, no Host Unit with an identification number of zero 
would txi~ at ±e Host Site. In this instance, the Remote PC 
would presently be connected directly to the "Data In" 
receptacle of ±e trst Host Unit oo the Daisy chain. In this 
case, the first and ail other Host Units present on the 
daisy-chain listen for an access request 

After this uuuaiizauoa process is complete, the Control 
CPU wait: to Process Access Requests 601 from the Remote 
PC to the Host Unit. During this time, the "Action** button 
on the front of the Host Unit is also monitored Should the 
** Action" button be pressed, then normally a "Setup** com- 
mand is sent to the Video CPU and a "Setup" flag is set, the 
setup indicator on the front panel of the Host Unit is made 
to blink, and the Process Access Request 601 routine con- 
tinues to wait. However, in cases where the Host Unit has 
been locked due to a security breach, pressing the "Action'* 
button unlocks the Host Unit for remote access and resets 
both the "Session" and Xockout** counters to zero. Finally, 
during thi: Proces: Access Request 6$1 wait period, any 
command received from the Video CPU will be serviced. 
Then, the Process Access Request 601 routine continues to 
wait 

When a Remote PC first establishes a connection with a 
Host Site (i.e. a earner detect signal or a request to send 
received), each Hon Unit on the daisy-chain at the Host Site 
re-imtLaiizec it's "Session" security counter to zero and 
session lockout 3ag. 

When a Remote PC issues an access request each Host 
Unit at the Host Site checks it's identification number 601. 
If the Access Request's identification number matches the 
Host Unit's number, then the Host Unit responds to the 
access request and Password processing 602 begins. 
However, if the unit is currendy in a SETUP mode, the 
Process Access Request 601 responds BUSY and access is 
denied. 

Routine 602 now requests a password from the Remote 
PC and waits. Presently, the Host Unit uses a zero knowl- 
edge password protocol, whereby each password request 
contains a random encryption key that encodes the password 
in a different manner, so as to make it difficult for anyone 
with unauthorized access to the data line to determine a 
password. 

If no password is received after a pre- set period of time or 
an invalid password is received 603. then a "Session** 
counter is incremented to count the number of unsuccessful 
access attempts during a session. If this counter exceeds a 
user specified lirmL the counter is reset to zero, a "Lockout" 
counter is incremented, a session lockout flag is set. and a 
data packet is returned to the Remote PC indicating that 
access to the Hcst Unit is denied for the session and 
processing returns to the Process Access Request routine 
601. If the "'Lockout" counter exceeds a user specified limit 
as obtained from no n- volatile RAM, no user will be per- 
mitted access to the Host Unit until the "Action" button on 
the front of the Host L T nit is pressed. 

If a valid password is received 603. both the "Session" 
and '^Lockout** counters are reset to zero, the session lockout 
flag is cleared and the Process Command routine is invoked 
604. 
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The Process Command 604 routine, processes any com- 
mands received frcra the Remote PC or the Video CPU. The 
Misc. Commands subroutine 6G8 cootains some subroutines 
that may be invoked by the Video CPU processing, after 
which processing will return to the calling routine when 
complete. 

The Release -Access command 605 is not a subroutine, 
but causes an end :c command processing by returning to the 
Control CPU's Pr^ess Access Request routine 601. 

The Pass thru 606 and Remote Access 607 routines are 
described after a general discussion of the Video CPU has 
been completed beiow 

Several processes are grouped together under the heading 
Misc. Commands 608. These processes include disconnect- 
ing the Host PC's keyboard from the Host PC so that the 
Control CPU can generate the keyboard signal. Also 
included are commands which start a video training session 
remotely, or transfer video related data (contained in non- 
volatile ram) to and from the Remote PC. change the Host 
Unit's password, or seixt a keyboard scan code to the Host 
PC (used by the video CPU during training). 

FIG. 5B is an overview of Video CPU's operating soft- 
ware. Lines with arrows indicate processing flow, whereas 
lines without arrows indicate a called process or subroutine. 

When power is nrst applied to the Host Unit, the Video 
CPU begins executing the initialization routine 620. This 
routine does nominal housekeeping such as setting certain 
variables to default values, setting up interrupt parameters, 
and initializing the Host Unit's data serial port 116 (FIG. 
4 A). After mis. the software waits for a command 621 from 
the Control CPU 107 (FIG. 4A). Blocks 622. 623A. 624. 625 
and the miscellaneous command 626 are all subroutines 
invoked by the Wait For Command 621 routine, which 
returns processing to the Wait For Command routine 621 
when subroutine processing is complete. Blocks 623A 
through 623E are parts of a single subroutine. 

If the Control CPU sends a video ready command, then 
the Load Video Related Data 623A subroutine is invoked 
and waits for one second, and then requests non-volatile 
video related data from the Control CPU necessary to 
decode the Host PC's video output. After this H*ta ls loaded 
into the Video CPU's memory 623A. the video processor 
hardware 110. 112. 113 (FIG. 4A) is initialized 623B with 
timing data, default sync polarity, and also flags are set to 
indicate the video processing mode (monochrome or color). 
Then, the Accumulate History 623E process begins to per- 
petually log the most recent VDAC output history to the 
extent of the Host Unit's memory. 

If the video mode changed from a text mode to a graphics 
mode, history logging within the Host Unit is suspended 
until the video mode returns to a text mode. 

The Accumulate History process 623E initially captures 
the text data currently displayed by the Host PC's VDAC 
which is stored in a "base screen" data area and after this, the 
Accumulate History Process only accumulates any changes 
which occur. If so many changes occur that the Video CPU's 
memory limit is reached, then the oldest changes are applied 
to the "base screen" data area to free up more memory so 
that more recent changes can be stored. 

When a Host Unit is jjoitially accessed by a remote user, 
the remote user must specify (via the TVUNKEXE pro- 
gram operating on the Remote PC, as discussed beiow) 
whether or not (1) any screen history stored in the Host 
Unit's memory should be transferred to the Remote PC prior 
to beginning the access session and (2) if the user wants 
view only access to the Host site, as opposed to full access. 
The user's preference on video history and view only mode 
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is transferred rc the Host unit as data packets when the Host 
Unit is first accessed If video screen history is to be 
transmitted, men :hc Accumulate History routine 623E 
transmits VDAC history data to the Remote PC by the Video 
CPU through the Control CPU's Misc. Command Routine 
608 in the form of data packets and processing returns to the 
Wait For Command 621 routine. Otherwise, the processing 
returns tc the Wait For Command 621 routine. 

If the remote user has requested full access to a Host 
Site's Host Units, as opposed to view only access, the 
Remote PC series a Remote Keyboard command to the Host 
Unit which invokes the Misc. Commands subroutine 608 
that causes ±c Host PC's keyboard signals to be generated 
by the Host Unit m stead of the Host PC's keyboard. Then, 
the Remote PC sends a Remote Access command to invoke 
the Remote Access 607 subroutine. 

First, the Control CPU Remote Access 607 subroutine 
instructs the Video CPU to begin it's Remote Access 622 
subroutine processing. The Remote Access subroutine 622 
causes video text to be captured and sent via the Control 
CPU to the Remote PC for display. The last status of the 
screen data sent is compared to the contents of the current 
screen and only changes in the VDM rfg ta are sent. 

FIG. 5C shows an overview of the data flows between the 
TVTJKFCEXE software executing on the Remote PC 630A. 
the Host Unit 630B. and the Host PC 630C Remote key- 
board 63 1A and mouse 63 UB activity arc handled by 
TVUNK.EXE .nterrupt processes which combine and trans- 
mits this data 633. 634 :o the Host Unit 632. The Control 
CPU 636a separates mis data, sending mouse information to 
the Video CPU 636B which forwards it as serial input 638 
to the Host PC. The keyboard data transmitted is converted 
to keyboard clock and data signals 637 which pass into the 
Host PC's keyboard input receptacle. Host PC Video signals 
639 from the VDaC are converted to coded text data, such 
as ASCII coded text data, by the Video CPU and transmitted 
through the Control CPU to the Remote PC 635 where it is 
processed by TVUNK.EXE for output to the Remote PC's 
VDAC. Note that me Taos mil and receive data lines shown 
at 632 may be connected directly or connected via modems 
or other coramunicarioc devices. 

To accomplish .lie transfers between the Remote PC and 
the Host PC. first a ajc-transfer program called TVFELE- 
S.EXE (provided with the apparatus and installed on the 
Host PC's mass storage device) is invoked on the Host PC 
by typing in the program name from the Remote PC key- 
board using the Remote Access process 607. Then the file 
transfer function is selected from the TVTJNKEXE menu of 
the Remote PC. TVUNK.EXE wOl then send a packet 
containing a Passthru command to the Host Unit. The 
Control CPU receives this command 604 and Passthru mode 
606 subroutine is invoked. 

The Passthru Mode 606 subroutine first sends a Passthru 
command to me Video CPU's Wait For Command 621 
routine which causes the Passthru 624 subroutine in the 
Video CPU to be invoked. The Control and Video Passthru 
606. 624 subro urines work together so that data received 
from the Remote PC is forwarded via the Video CPU to the 
Host PC's serial port. Data received from the Host PC is 
forwarded via the Control CPU to the Remote PC. Thus. 
TVUNX.EXE (running on the Remote PC) communicates 
directly with the file-transfer program (running on the Host 
PC) and it is the responsibility of these two programs to 
produce the file transfer either from the Host PC to the 
Remote PC or vice -versa. 

Video Training and Setup 625 is invoked when the Setup 
command is received from the Control CPU. after the Action 
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button is pressed on the from panel of the Host Unit. This 
process interfaces with a software program running on the 
Host PC C2llcd TVTRAIN.EXE. which is provided with the 
apparatus and accessible from the Host Unit's mass storage 
device, as discussed in the narrative supporting FIG. 6A to 
6D. To send data to the program, the Video Training and 
Setup subroutine 625 commands the Control CPU to send 
"keystrokes" to the program, and receives data from the 
program by processing the VDACs video signals including 
a video raster signal. This process is described in more detail 
in connection with FIGS. 6 A. 6B, and 6C. 

During Remote Access 622 and Video Training and Setup 
625. certain subroutines are used to capture and interpret 
video data. Video graphics is captured and digitized by the 
Capture Video 640 graphics subroutine. This subroutine first 
checJcs that the horizontal sync and the vertical sync did not 
change in polarity, and then waits for the vertical sync to 
become active, at which time it enables the video processing 
circuitry and waits for the next vertical sync. At this point, 
the video output buffer contains the digitized video data. 
This data is then transmitted to the Remote PC where 
TVLINKEXE program can display this data in graphics 
mode. This data is also used by the training process 
(described below) to adjust pixel clock timing. The video 
circuitry must be properly initialized (see 110. 111. 112. 113 
FIG. 4A) without CRC 

If the polarity of tne sync signals change 641. this routine 
aborts and returns 642 the Video Status. Otherwise the 
Capture Video 640 graphics subroutine returns OK 643. 

To capture video text, the video circuitry must be properly 
initialized (see 110, 111. 11Z 113 FIG- 4A) for text mode 
with CRC. Then, the Capture Video 644 text subroutine 
captures video text and 2000 CRCs (for a 80 character by 
25 line text mode;. Presently, both the Graphics and Text 
Capture Video subroutines 640. 644 are the same subroutine. 
This results because the video processing circuitry is ini- 
tialized differently that character CRCs. rather than digi- 
tized video, is stored into the video output buffer. 

If the sync polarities have changed 64S. Capture Video 
644 subroutine processing ends and the video status is 
returned to the calling routine 646. Otherwise, the video 
circuitry loads each character CRC from the video output 
buffer and. via a look-up table, translates these CRCs to 
character codes (such as one byte character codes used by 
the ASQI coding scheme) stores these codes into memory 
via a data-pointer which was initialized prior to calling this 
subroutine 647. and then returns OK 648. 

FIG. SB shows the Capture Video 644 subroutine (at 
650B. 65 IB. 6S2B) being used to capture text data from the 
red, green, then blue color signals. Before capturing text 
data, the particular color signal is selected at 650 A. 65 LA.. 
652A (discussed previously in the narrative for FIG. 4Q'h 
The Capture Video Text 650B. 65 IB. 652B subroutine will 
return the video status 630D. 651D, 652D if the sync 
polarities change 650C. 651C 652C. Otherwise, the Capture 
Video Text subroutine returns OK at 653 after capturing 
video text information from die Red, Green and Blue color 
signals. 

FIG. 5F illustrates some of the data storage areas used by 
video subroutines. The character data generated from the 
Capture Video Text subroutine 650B. 65 IB, 652B is stored 
into corresponding data areas 660 A. 661 A. 662A. These 
subroutines also update a bit flag (in 660B. 66 IB. 662B) for 
each character. A bit flag indicates whether a character is 
normal or inverse (highlighted). 

Using the red. green, and blue text data and bit flags, each 
character value, such as the ASCH value, and color attributes 
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(foreground and background) can be determined. FIG. 5G 
shows 5 characters 665 A. 665B. 66SC. 665D. 665E. each 
with different foreground and background coior combina- 
tions. For each of :rtese. there is also shown the characters 
derived from the mrss color signals after each signal is used 
to derive the relates CRC. The foreground and background 
colors will be each represented by a three bit number with 
each bit corresponding :o one of the three primary colors. 
This three bit quasar, can take on values 0-7. where black 
is 0 (OOCbj. blue .s 1 ' 001b;. green is 2 (010b). light blue is 
3 (011 red :s 4 .' I OCc , . violet is 5 ( 101b), yellow is 6 ( 1 10b) 
and white is 7 ( 111b . The preceding numbers in parenthesis 
are the binary equivalent of the three bit value and will be 
used in the discussion. The combination of red, green, and 
blue light naxc white. In cases where the analysis of 3 coior 
signal yields a CRC that is "aormar video, the correspond- 
ing bit value of thai signal will be 1 for ON and 0 for OFF. 
Otherwise, if the signal matches an inverse CRC, the bit 
value of the signal will be reversed (i.e. set to 0 for OK and 
1 for OFF;. 

The process of bow the three-color primary color signals 
are used to derive the foreground and background colors is 
illustrated in FIG. 5G and FIG. 5H. 

For White (foreground) on Black (background) 665 A. 
each coior signal maxhes a "normal" CRC for an "A". 
Accordingly, 666a shows a red "A" on a black background, 
which means the red signal is ON for foreground (i.e. 1) and 
OFF for background ':.e. 0) Similarly. 667A shows a green 
**A" and 66SA shows a blue "A", also on black backgrounds. 
Together these three coior signals appear on a computer 
monitor as a white "A" 00 a black background. On this basis 
the bit values would yield: Foreground: II lb, background: 
000b. 

For White on Blue 66SB. the blue signal 668B is always 
on. It supplies the blue background color and it also com- 
bines with the red "B" 666B and the green "B" 667B to 
create the white foreground color of the "B". The CRC for 
the red and green signals yield a "normaH B character. 
Hence, the first rwo foreground bits are "11" and background 
bits are "(XT. The CRC for me blue signal yields a "normal" 
soiid blue block CRC character where both the foreground 
and background colors arc blue (i.e. ON). Hence, both the 
third foreground and background bits would be set to 1. On 
this basis the bit values would yield: Foreground: 111b. 
background: CO lb. 

For Yellow on Blue 665C, the red "C* 666C and the green 
**C" 667C are ON and combine to create the yellow fore- 
ground coior. When the red and green signals' CRCs are 
analyzed, a "normal" CRC "C* character results, which 
means the first two bits are set to foreground value of 1 and 
a background value of 0. When the blue signal's CRC is 
analyzed, the blue signal 668C forms the background only 
and is not par: of the foreground coior. since the signal 
matches a "inverse" CRC for the letter "C*. On this basis the 
bit values would yield: Foreground: 110b, background: 
001b. 

For Red on Blue 6^5D. the red "D" 666D creates the 
foreground coior and hence matches a "normal" CRC for the 
letter "D". So. the first bit would be set to 1 for the 
foreground and 0 for the background. The green signal 
66713 is off. or black: does not contribute at all; and matches 
the CRC vaiue for a "normal" space. So the second bits for 
both the foreground and background would be set to 0 (i.e. 
OFF). When the blue signal's CRC is analyzed, the blue 
signal 668D forms the background only and is not part of the 
foreground color, since the signal matches a "inverse" CRC 
for the letter "D". On this basis the bit values would yield: 
Foreground: 100b. background: 001b. 
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For Yeiiow on Violet the red signal 646E is always 
on and with the green VC E~ 667E combine to create the 
yeiiow foreground color and combines with the blue back- 
ground color 668E to form violet. Since the red signal is 
"OK" to achieve both the foreground aad background 
colors, the red signal matches the "normal" CRC for a block 
character and the first bit for both the foreground and 
background wcuid be set to L The green signal combine 
with the red signal to dchne the yeiiow foreground for the 
T character, but is not a pan of the background color and 
is hence OFF for background purposes. On this basis, the 
green signal would match the CRC for a normal "E" 
character and cause the second bit to be set to 1 for the 
foreground and 0 for the background. The bine signal 
does not contribute to ±e foreground but contributes to the 
background and combines with the red signal 666E to form 
violet. When the blue signal's CRC is analyzed, the blue 
signal 66SE forms the background only and is not part of the 
foreground coier. since the signal matches a Inverse" CRC 
for the letter **E*\ On this basis the bit values would yield: 
Foreground: II Ob. background: 101b. 

For Yellow on Green 665E the blue signal 668F is off. or 
black, and does not contribute anything. Hence, the blue 
signal translates to a CRC for a "normal" space, where the 
third bit would be off for both the foreground and back- 
ground. The green signal 667F supplies all of the back- 
ground color and also combines with the red signal 666F to 
create the yellow foreground color. Hence, the CRC for the 
green signal yields a "normal" block character where both 
the foreground and background for the secoed bit would be 
set to **r\ The red signal only contributes to creating the 
foreground of the ' 4 F\ Hence, the red signal would yield the 
"normal" 'IT character which would set the first bit to a 
foreground of 'T and a background of **0*\ Oo this basis the 
bit values would yield* Foreground: 110b. background: 
010b. 

For Black (foreground) on White (background) 665 G. 
each color signal is identical and yields Ihe CRC for an 
"inverse** "G" character. 666G shows a black "G" on a red 
background. Similarly 667G shows a black on a green 
background and 668G shows a black "G** on blue back- 
ground- Together these three color signals appear on a 
computer monitor as a Black t *G" on a white background. 
On this basis the bit values would yield: foreground: 000b. 
background: 111b. 

Other characters follow a similar partem, except for those 
characters which result in a solid block or a space. 

When an analysis of ail three color signals yields a 
character that is a solid block 665X. 645Y. 665Z. the 
character ASCII code is always stored as a hex DB block 
with both the foreground and background ^tributes set to 
the color of the block. This approach improves processing 
efficiency as discussed below. 

A Black block is shown at 665X. All the color signals 
666X. 667X. 668X. are off. or black. The CRC for each 
color character 66<5X. 667X. 66SX will be translated to a 
"normal" space character (ASCII hex 20) but the character 
at 665X will be set to a block (ASCII hex DB) with 
foreground of 000b and a background of 000b. 

A While block is shown at 665 Y. All 4c color signals 
666Y. 667Y. 668Y, are on. The CRC for this character will 
be translated from each coior signal to a block (ASCII hex 
DB). On this basis the bit values would yield: foreground: 
111b background 111b. 

A Yellow block is shown at 665 Z. The bine color signal 
66SZ is off. or black, and does not contribufe anything and 
hence is translated to the "normal** CRC ^ace character. 
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The red 6662 a ad the green 667Z arc on in both the 
foreground and background to combine to make the solid 
Yellow Block. The CRC for this character will be translated 
to an ASCII vaiue of hex DB. On this basis the bit values 
would /:eii foreground; 110b Background 110b. 

The ASCII hex 00 (null character) and ASCII hex FF 
character; are identical (as displayed) to a solid block 666X. 
666Y Presently, these characters are translated to a block 
(hex DB, character. The ASCH code 00 is used to represent 
a character ~ ho' s CRC is unknown (not in the CRC look-up 
table; This can occur for two reasons. One. when noise, or 
other transients corrupts the video signal, and two, when the 
presence of the Host PC VDAC's hardware flashing cursor 
periodical y obscures the character. The ASCII code hex FF 
is denned as an invalid character and is used to clear 
(initialize, .ASCII video data areas. 

A discussed above, a "normal" character is defined as a 
foreground coior on black background such as 666F. 
Whereas an inverse or "highlighted", character is defined as 
black oq a background color such as 666G. A character CRC 
will uniquely identify whether a particular character is 
normai or inverse depending on whether the applicable color 
signal is translated to a character using the "normal" or 
''inverse" character set. When examining the red, green, and 
blue characters, each character can be one of the following 
ASCII codes, a space (hex 20) 666X. a block (hex DB) 
666Y. or the ASCII code of a particular character 666F or 
666G. So. x deriving the three bit foreground and back- 
ground color values, the process is as follows: for each 
particular color, if the character is a space, which is all black, 
then the foreground bit and background bit for this color are 
both set to zero If it is a colored block character, then the 
foreground bit and background bit for the color are both set 
to one. Otherwise, the character normal/inverse Sag deter- 
mines the setting of the color bit: normal sets the foreground 
bit and inverse sets the background bit. 

To determine a character code, if all three color characters 
are either spaces or blocks (such as 665X, 665Y. 665Z). then 
the character is a block 665X. Otherwise, the character is 
any non-space, non-block character found (such as 665F). Jf 
there is more than one non- space, non-block character, they 
must be equal If two such characters arc encountered and 
arc not equal then die character is set to hex 00 (unknown 
character;. Also, if any color character is unknown 
(unrecognized CRC). then the resulting character is also set 
to hex 00. 

The character comparison, to determine the differences, as 
referenced above, include both the ASCII code as well as the 
color attributes. If foreground color changes from one char- 
acter to the next, then this color change iiiformation is 
processed. If background coior changes from one character 
to the next, then this color change information is processed. 
If the character code changes, the new character will be 
processed. Blocks (ASCH hex DB) need special attention 
because they may be interpreted as spaces depending on the 
foreground and background coior values. For instance, if 
White on Black text is oeing processed, such as 665A, then 
the Black block 665X will be a space (hex 20) and the White 
block 665Y will be a block (hex DB). If however. Black on 
White text is being processed then the space 665X 

will become a block since the foreground color is black. 
Similarly, the White block 665Y will become a space since 
the background color is White. This is determined by 
exarnining previously processed character' s color attributes. 
If the entire video screen is blank (all spaces being 
displayed) this may be interpreted as 2000 spaces with Black 
background or 2000 blocks (Black foreground). It does not 
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matter, since they arc equivalent. The only reason to differ- 
entiate spaces rrcra blocks is for efficiency since oniy the 
ASCII code need be processed, rather than processing 
foreground and background information. Since typical 
screens axe composed of a significant amount of blank space, 
avoiding the need to process foreground and background 
information improves overall performance of the video 
signal translation process. 

From the above discussion it will be clear to person of 
skill in the an that the color attributes of the characters 
displayed on the Host PC VDM can be interpreted and 
transmitted to a Remote PC using the present invention. The 
examples listed above are illustrative of the method 
employed by the present invention, which can be used to 
determine the color attributes of any characters displayed on 
the Host PC VDM. 

When video text is 5rst processed for remote access, the 
Current Screen 663A is initialized to hex DB (the block 
character) and color attributes 663B arc imtialiued to zero 
(black foreground and background). These two data areas 
comprise the current text data captured and represent a Wank 
screen. Each new captured text screen is then compared to 
this current screen data and only the differences are pro- 
cessed (i.e. either sent to TVLJNTfCEXE or logged as 
history) and updated to the current screen data. Thus, by 
initializing the current screen data with hex DB and color 
attribute of zero, only the first non-blank video text data 
captured is guaranteed to be different, and thus be com- 
pletely processed. After this, oniy the differences will be 
processed. The initial text data and subsequent differences 
will be transmitted to the Remote PC via the Control CPU. 
Transmitting oniy changes over relative slow speed tele- 
phone lines substantially reduces the amount of time 
required to transmit Host PC video display information to a 
Remote PC. Furthermore, using data compression tech- 
niques familiar to persons in the trade further reduces the 
time needed to transfer data to a Remote PC. 

To accumulate video text history, video text data is first 
captured and stored into the current screen 663A and the 
Base Screen 664 A data areas as well as the color attribute 
data areas 663B. 664B. .After newly captured text data is 
compared to the current screen data, oniy the differences are 
stored by the Accumulate History routine 623E in the 
History of Changes 664C data area and then updated to the 
current screen data. When the History of Changes data area 
664C becomes full, the oldest changes are applied to the 
base screen 664a. thus freeing more storage space 664C 

Some Remote users may wish to sacrifice color attributes 
for faster transmission of text data. Presently, the remote 
user is given the op don (via the TVLINK-EXE program 
running on the Remote PC. discussed later) to chose 
between one of the three color signals in lieu of color 
detection using all three color signals, as previously 
described. When one color signal is selected, the Video CPU 
processes only that color signal and sends back normal and 
inverse video text data. In certain cases, characters may be 
formed solely by color signals other than one signal selected. 
In these cases, the correct character cannot be determined. 
For example, a blue character on a black background will 
not be detected on either the green or red color signals. 

The Control CPU's keyboard interface emulates the Host 
PC's keyboard. Keyboard signals (either from the keyboard 
or the Control CPU) pass through two stages before reaching 
the application program running on the Host PC. The 
application program could include the DOS COMMAND- 
.COM program. When any key is pressed and/or released, 
the keyboard sends one or more serial data bytes to the Host 
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PC. These bytes are processed by a dedicated micro- 
con troUer within the Host PC. which translates this infor- 
mation to sczz codes, and asserts interrupt 9 to communicate 
to the Host PC's central processors (for example a 80386 
microprocessor; This interrupt invokes a BIOS routine 
which translates the scar code to an ASCII (or extended) 
character co<ie ajic places :t in a buffer for use by the current 
application. A*:nougc some application programs may 
bypass the BIOS arc service this interrupt directly, it will 
not affect the operation of the present invention. Examples 
of extended character codes include the HOME. LEFT 
ARROW, and INSERT keys. 

The keybcarc uses a bi-directional synchronous serial 
protocol C8 bit plus parity; :o communicate with the Host PC 
and the Controi CPU emulates this interface when a Remote 
user is accessing a Host Unit. FIG. 51 shows the keyboard 
clock 671A and data 67 OA signals. These signals are held at 
a logical high o: 5 voits by a pull-up resistor. The Host PC 
or keyboard assert a logical low (0 volts) on these lines by 
use of an open-coiled or driver. For each bit transmitted data 
is first asserted • high or low) (i.e. 670D) after which the 
clock is driven low for approximately 50 microseconds (Le. 
67 1C). The transfer of lata is controlled by the keyboard, 
not the Host PC. Thar is. when clocking data to or from the 
Host PC. it is ;hc keyboard which produces the clock signal. 

When a key is pressed, the keyboard sends a byte or bytes 
to the Host CPU. It first asserts a serial "start" bit 67$B. 
asserts a clock pulse 67 IB. then asserts the first data bit 
670C. and so cs. unui the 3th data bit 67 0E and parity 670F 
has been clocked- Then, a stop bit 67 OG is asserted with 
clock pulse 671 D. This ends the byte transfer. At this time, 
when the ciocx pulse is brought high 67 IE. the Host PC 
asserts a low on the clock line. This will remain low 671F 
until the Host PC has finished processing this data byte, at 
which time, th; clock line will go high 671G and the 
keyboard can send another byte. For keystrokes such as. for 
example "A" through "*7T , 670A and 671 A show the pro- 
tocol involved, lata 3cw is from the keyboard to the Host 
PC. 

For keys such as CAPS-LOCK. NUM-LOCK. and 
SCROLL-LOCK, data flows both ways. That is. the Host PC 
controls the sta:c of these functions. When the NUM-LOCK 
key is pressed, for example, the keyboard sends this infor- 
mation to the Host PC after which the Host PC sends the 
status of all three functions which activate the NUM_ 
LOCK. CAPS-LOCK, and SCROIX-LOCK indicators on 
the keyboard. The clock and data protocol for this is shown 
at 672A and 673A. When the NUM LOCK key is pressed, 
the start bit 672B and first clock 673B begins the byte 
transfer. After the byte is transferred, the keyboard brings the 
dock line high 673C which the Host PC will immediately 
bring low again 673D to indicate busy. During this busy 
time, the Host PC brings the data line low 672C to request 
a data transfer to the keyboard. When this happens, the 
keyboard waits for the Host PC to set the clock line high 
again 673E at ^hich time the keyboard now generates the 
dock pulses 673F Note, that the data signal at 672C also 
serves as the start bit. With each clock signal, the keyboard 
shifts the Host PC's data 672D into its memory. When the 
transfer is done, the keyboard sets the clock line high 673H 
and the Host PC brings it low again 673G to indicate busy. 
When finished, the Host PC brings the dock line high 673J 
to indicate it is ready for more keyboard data. If after the 
Host PC has brought the clock line low 673G and the Host 
PC has more data, the data line is again brought low as 
illustrated at reference 672C and another data transfer, from 
the Host PC to the keyboard, will take place. 
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This concludes an overview of the clock and data proto- 
col Aithough one -byte transfers arc described to explain the 
mechanisms for ci-oirectionai data transfer, when a key is 
pressed, release! or for •'lock" key activity (NXTM-LOCK- 
etc.) multi-byte transfers are actually involved. Keys such as 
Print-Screen. Sys-Req. zr CLT- Break also have their own 
multi-byte protocol More iecail concerning this operation is 
set forth in :he raicrcricfce appendix, part 7. 

FIG. 6A illustrates the main training screen 681 presently 
generated by the TvTRAlNiEXE program distributed with 
the apparatus. The source program code for the TVTRAlN- 
.EXE program is inciudea ;n the microfiche appendix part 4. 

Processing parameter: needed to decode the video signals 
for a VDAC into digiiai or text data may vary from VDAC 
to VDAC and may change further should VDAC technology 
change. The TVTRAIN EXE program is invoked on the 
Host PC. The program permits the Host unit to decode the 
actual video output signals of a VDAC. including the video 
raster signals, against known data displayed on the screen to 
deduce the exact processing steps required to decode the 
output of the VDAC. This approach permits the apparatus to 
process video regardless of the VDAC technology 
employed. These processing parameters are stored in the 
form of data tables stored in the Host Unit's non-volatile 
RAM. which are referenced by software programs operating 
in the Host Unit Video CPV that decode the Host Unit's 
video signals. Once the TvTRAlN.EXE process has been 
successfully completed for a HOST PC the process need not 
be repeated unless the Host PC's VDAC or VDM is changed 
or a new Host PC :s connected to the Host Unit 

When the TVTRAIN.EXE is invoked on a Host PC. the 
Host PC waits for a specific series of keystrokes to be 
received from the Host Unit to begin the training process. 
Thereafter, the Host Unit controls the activities of the 
TVTRAIN.EXE program via keyboard input to the Host PC. 
After the TVTJNTCEXE has been invoked on the Host PC. 
the "Action" button on the front of the Host Unit must be 
pressed to instruct the Host Unit to begin sending keyboard 
data to the Host PC. Thereafter, the Host Unit continues to 
control the TVTRAIN.EXE via. keyboard input until the 
training process is complete. When training is in process the 
"Setup Mode" indicator Ugh: on rhe front of the Host Unit 
blinks. 

During the raining process a video screen is presently 
displayed on the Host PC VDM as shown in FIG. 4A. This 
video display uses only black and gray or white unless 
otherwise noted. 

The dashed horizontal tine beginning at reference 683 
shows 40 half block characters (hex DF) from the ASCII 
character seL Each of these characters alternate with a space. 
The next solid horizontal line beginning at reference 684 
contains 80 half block characters {hex DF) forrrjing a solid 
bar. The third vertical line beginning at reference 685 
through the twenty- fourth 687 row contain a hex Bl char- 
acter in the first column (also shown enlarged at 680A. The 
twenty-fifth line CLe. row) contains 80 characters (hex DC) 
as shown beginning at reference 688. 

As the first step in the training process, the horizontal and 
vertical sync polarities are determined and then the video 
processing circuitry is initialized to digitize the video data 
(the CRC configure latch 429 is set to zero) by the Video 
CPU in the Host Unit. There are 8 pixel clocks per character 
and with 80 characters per row, a total of 640 pixel clocks 
arc needed. Each of these pixel clocks is initialized to a small 
default value to place them approximately 25 nanoseconds 
parts. 

Then, to determine whether the video signal is analog or 
TTL, the green analog signal is selected and video is 
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captured The * ideo data is then scanned for biack and white 
activity whicn "*lJ be found when data relating to 683 is 
encountered. If :rie data is ail zeros cr all hex FFs. then the 
monitor is not analog and the TTL green signal will be 
selected, and vioco activity checked again. If video is still 
not detected, ien :ne v : dec CPU instructs the Control CPU 
to send a kr. i~zcz to the Host PC. via the keyboard 
interface, insrvctias TVTRAIN to display an error message. 
Otherwise, the vice 3 raining process continues. 

Next, a video :cretQ is captured. First, the number of 
non-display able horizontal scan lines 682 must be deter- 
mined. This is loce oy counting each 80 byte (one scan line) 
until a n on -blank: scan Line is found (i_e. reference 283). 
Second, starting **i:h ±c firs: non-biank scan line 683. scan 
lines are counted, usul tne next horizontal line (i.e. reference 
684) is encountered. This gives the number of horizontal 
scan lines needed 10 generate a character. 

With this information, the training process continues to 
capture the video, ignoring the first two rows 683, 684 and 
begins adjusting the pixel clock tunings using the columns 
in the vertical lice between 685 through 687. This column 
685 is shown in mere detail at 680A. The blank space 
referenced at 680 B zhc^s the first pixel of the character hex 
Bl. The black square referenced at 68*C shows the first 
pixel of the next ;can ine. The series of blank and black 
squares referenced by 680D shows the first character in it's 
entirety. In a VGA mode 16 horizontal lines are needed to 
make die character. The next Character referenced at 680E 
immediately follows ±c first character thus supplying an 
unbroken sene: of alternating pixels (i.e. 680B. 6S0C and 
downward). The vertical column of hex Bi characters 
indicated by 685 to 687 include 352 horizontal scan lines for 
VGA text mode video < 1 6 scan lines by 22 rows). For some 
monochrome adapter cards using 8 scan lines per character 
row. there are only 176 scan lines. In any case. 100 scan lines 
of the column 685 to 6S7 are used in the training process. 

FIG. 6B shows the first four horizontal scan lines of 680A 
and associated data streams. The pixel referenced at 68 OB is 
shown again at reference 690B. The 8 character pixels 
starting with 690B is shown as a data stream at 690F. 
Similarly. 690C is shown at 690G. 690D is shown at 690H. 
and 690E is shown at 690J. Pixel docks positioned correctly 
are shown on the line beginning at reference 690K. Correct 
positioning is when, the pixei clock will reliably capture 
pixel data without errors due to jitter. Pixel clock 690M 
captures the first pixel or data bit. the following 7 pixel 
clocks captures the re maini ng 7 pixels, producing a data byte 
for each scan line. The value of this byte for 690B. 690F is 
55 hex or 01010101 binary. The value of the next byte for 
690G is AA hex cr 10101010 binary. The first pixel 
is the Most Significant Bit (MSB) of the resulting byte vaiue. 

Note that as shown, the first pixel 68#B of the character 
hex B 1 is a zero data bit and that 680C is a one data bit. For 
some video adapter cards however, the hex Bl character is 
reversed. That is. the first pixel 6 SOB of the character hex B 1 
is a one data bit and that 68OC is a zero data bit. Since the 
Host Unit knows the expected character contents of each 
screen location, the Host Unit can automatically detect this 
reversal, which illustrates how the apparatus can automati- 
cally adapt itself to diverse VDACs through this training 
process. 

A primary subroutine involved in the training process 
evaluates the correctness of a pixel clock position in relation 
to the video pixel data. This routine processes 100 scan lines. 
Each scan line is digitized to 80 bytes, each byte represent- 
ing one scan line of a character. Before calling this subrou- 
tine an INDEX and a MASK vaiue is set The INDEX 
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selects one of the 80 bytes across the screen. The INDEX 
starts at zero. *hicn is the left most column, moves across 
the screen one column ai a time and ends at 79. which is the 
right mosr screen column 689B. The MASK selects one of 
the bits within a byte referenced by this INDEX Reference 
690R show a ucie of these MASK values. 

As the first :tep in this subroutine, the pixel at 690B is 
tested. If it is zero, then a COUNTER is incremented. Then 
the pixel at 6^C is rested. If it is non-zero, then a 
COUNTER is also incremented. This is repeated for pixels 
690D. 690E. and so on. testing for alternating pixel values, 
until 100 pixels have been tallied. The value of the 
COUNTER should now equal 100 and. if so. then the pixel 
clock 690M is correct. If it is less than 100. then the pixel 
clock needs to be repositioned, and the pixel column 690B 
re checked. 

After pixel dock 690M is positioned correctly, then pixel 
clock 690N is selected. At this point, the first pixel in this 
pixel column (to the right of 69GB) will be a one instead of 
zero at 690B. 

Initially, the INDEX for the pixel clock referenced at 
696M is set to zero and the MASK is set to hex 80. After the 
pixel column is processed and the COUNTER equals 100, 
then the MASK is shifted right to become hex 40. to test 
690N. then it is set to hex 20 for 6900. and hex 10 for 6900. 
until the eighth pixel column is processed with the MASK 
equal to hex 01. The eight pixel clocks for this column of 
characters (i.e. 685 to 687) arc now positioned 

The Video CPU now instructs the Control CPU to send a 
keystroke to the Host PC. via the keyboard interface, which 
instructs the TVTR.-VIN.EXE program to move the column 
of hex B 1 characters 685. 687 over to the next column at 
689A. The training process now increments the INDEX by 
one and sets the MASK to hex SO. and proceeds to position 
the next 8 pixei clocks 690Q. This process is repeated until 
the last column at 689B has been processed (INDEX equals 
79). The pixel clocks now correctly capture the 640 pixels. 

When the horizontal scan line begins 6 90 A. there is a 
blank area or left margin 686 before visible pixels com- 
mence. When atternpong to position the first pixel dock at 
690M. it may be at 690L or some other location. Notice here 
that the data streams 690F. 690G. 690H. 690J and so on, will 
all have a value of zero. So when the subroutine, described 
above, processes this data, the value in COUNTER will be 
50 since only half the pixels are of the correct value. That is. 
they are all zero whereas the subroutine expects alternating 
pixel values. On this basis, the training process permits the 
unit to automatically adjust to the blank areas present for a 
given VDAC by skipping over situations where the vertical 
pixel counter is 50. 

Signal interference or noise may cause minor distortions 
during the training process in the pixel COUNTER. 
Therefore, a tolerance of plus or minus 3% is presently 
permitted when setting the pixel clocks. In addition, in cases 
where a pixel clock appears to be out of such expected 
ranges, processing for the pixel clock is automatically 
repeated up to 10 times to resolve the problem. If the 
problem cannot be resolved at that point, the training process 
is terminated and an error messages is displayed suggesting 
that another VDAC or Host Unit be used. 

FIG. 6C shows the effect of pixel clock timing on the 
COUNTER value. Waveforms 692Aand692B show several 
pixels from two scan lines including jitter 692M. Waveforms 
692C 692D. 692E, 692F. 692G. 692H. 692J show the pixel 
clock pulse of 690N at different tuning positions. This pixel 
clock as shown at 692H is correctly positioned for 690N. 
The pixei clock shown at 692C is actually positioned at the 
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preview ptxri 69«M. 690B, 690C The COUNTER value 
results g 'Jms clock pulse will be zero because none of 
the p&ej, are correct As explained, pixel clock 690N 
expects * consistent pixel value of one 692K followed by a 
pixel va.^ of zero 692L. 

At 692^ uie COUNTER value will be approximately 10 
because l^s :o utter, the pixels will be correct 10 percent of 
the time 

At 692E ±e COUNTER value will be approximately 50. 
At 692F Jie COUNTER value will be approximately 90. At 
692G. £c COUNTER value will be close to 100 (due to 
insu&cizz: lata setup time requirements). At 692H. the 
COUNTER vaiue will be 100. At 692J, the COUNTER 
value will again be close to 90. 

After t^e pixel clock timing has been determined, the 
Video CPU instructs the Control CPU to send a key stroke 
to Host PC. via the keyboard interface, instructing 
TVTRAIN EXE program to display the character set as 
shown on FIG. 6D. Both normal and inverse (highlighted) 
characters are rhown. At this time, the Video CPU enables 
CRC generation by setting the CRC configure latch 429 to 
the value of hex 33 ( which will select the two least signifi- 
cant bits acc ±>e most significant bit of the shift register 439, 
for feedback 426; 

The vidzc is :r»en captured producing CRCs for each 
character t.icwn on FIG. 6D. Presently there are 512 pos- 
sible characters (256 normal. 256 inverse) that may be 
displayed on an Host PC's VDM operating in a text mode. 
Some jf these cnaraaers are duplicates. For instance, the 
zero ASCII cocc. or null character at 693 A. and the hex FF 
character 693C iocs not display on a VDM and is the same 
as the space character 698B. and will be interpreted as a 
space ("hex 20). Similarly, the block character (above the 
square root sign and near 69SQ is identical to the inverse 
null 698D and ar. averse space 698E. and will be interpreted 
as a block. Although, the ASQI codes differ among these 
two sets of characters, the visual information is identical. 

Only ihe CRCs for the character sets on HG. 6D are 
presently processed. First, they are checked for uniqueness 
(ignoring lupLcaic or identical characters). If they are not 
unique, thee a new value must be written to the CRC 
configure latch 429. such as hex 85. etc. The video is again 
captured and the uniqueness test is repeated When a suitable 
value for the CRC configure latch, which provides for 
unique CRC codes for all characters is found, video training 
continues. 

If the VDAC is analog (not TTL) tiien the Video CPU 
instructs the Control to send a key stroke to Host PC. via the 
keyboard interface, ins^ucting TVTRAIN.EXE to eater a 16 
color 640 by 4S0 graphics mode and display a single 
horizontal bar at the top of the screen. The horizontal and 
vertical sync polarities are determined for this mode and 
then the video processing circuitry is initialized to digitize 
the video data 'the CRC configure latch 429 is set to zero). 
The number of horizontal scan lines 682 preceding any 
visible pixels is then determined. 

All information gathered during this video training pro- 
cess including the pixel timing information and character 
CRCs are transferred to the Control CPU for storage in 
non-volatile RAM. A flag in non-voiatile ram is then set to 
indicate the Host Unit has been successfully trained and the 
SETUP indicator light 54 is turned off. 

When the training process is complete, the Video CPU 
instructs the Control CPU to send a keystroke to the Host 
PC. via the keyboard interface, informing the TVTRAJN- 
JEXE program that training was successful. At this point the 
Host PC returns to it's normal operating system (e.g. DOS). 
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FIG. 7 ls a block diagram describing the software pro- 
cessing presently occurring within a Remote PC. Rectangu- 
lar objects on this diagram represent software subroutines or 
menu displays that may be initiated within the Remote PC's 
CPU whenever a program (herein referred to as 
TVLINK-HXE) supplied as pan of the apparatus is executed. 
Diamood shaped boxes represent major processing deci- 
sions occurrmg within the TVTJXK.EXE program Circled 
boxes with letters inside represent either on-page or off-page 
connectors to the next processing step in the block diagram 
Lines with arrows represent me direction that TVUNK.EXE 
processing flows. 

Source program code presently used for TVUN1CEXE is 
contained in part 3 of the microfiche appendix. TVUNK 
software is installed on each Remote PC that will access 
Host SitcCsj. 

TVUNK.HXE processing begins at block 700 on FIG. 
7A. When the program is first invoked, a System Main Menu 
is displayed 701 with three processing options. The first 
menu option. Setup System 702. permits configuring the 
system to the user's specific requirements and the hardware 
configuration of the Remote PC where the system is being 
installed The second menu option "Call Host Site" 703 
permits the user to cause their Remote PC to call and link to 
a desired Host PC. When this menu option is selected, a call 
list of Host Units that may be selected is displayed 704. This 
call list is created and maintained as part of Setup System 
702 processing. When a Host Unit on the list is selected, the 
program initiates linkage processing to the selected Host 
Site, men links to the requested Host Unit Once linked a 
password is requested by the Host Unit using a password 
transmission key based random number that causes the 
password transmitted by the Host Unit to be encrypted 
following a procedure set by the key. This approach makes 
it difficult for someone to decode a password being trans- 
itu tied from a Remote PC to a Host Unit by tapping into the 
communication line. If an invalid password is received by 
the Host Unit, a "session** lock out counter for the Host Unit 
is incremented by one. If this counter exceeds the limit set 
for the session (sec block 734 processing below), me user is 
locked out from any further access attempts to the Host Unit 
for the current session and a Host Unit lock out counter 
stored in non-volatile RAM in the Host Unit is incremented 
by one. If the Host Unit lock out counter exceeds the limit 
for the Host Unit (see block 734 processing below), all 
access to the Host PC will be blocked until someone presses 
the Action button on the front of the Host Unit. 

If a connection is made to the selected Host Unit 705, the 
TVLJNK.EXE program pops up a menu on the screen with 
two choices pennitring the Remote user to either select a 
normal access mode or a view only access mode. In a normal 
access mode, the user has full keyboard and video access to 
the Host Unit In a view only access mode, the user has only 
the capability to view the output of the Host PC's VDAC 
Next, processing continues at block 742. If the Host PC is 
not turned ON or the Host Unit is not properly connected to 
the Host PC, the Host Unit will return an error that no Host 
Video signal is present, but the connection to the Hosi^Unit 
will continue until terminated by the Remote User for the 
possible purpose of retrieving any VDAC screen history that 
may be present in the Host Unit. 

If a connection cannot be completed to a Host Unit 705, 
an appropriate error message appears on the Remote PC 
VDM screen indicating why the connection could not be 
completed and the System Main Menu 701 is redisplayed. 
The final System Main Menu option. Exit System 70S 
terminates TVUNK.EXE program processing and returns 
control to the Remote PC's operating system 
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When T'TJMCEXE program is executed for the first 
time on a Remote PC. Ac Setup System 702 main menu 
option is sc.cr.e4 first 10 ' I) define whether the li&kage to a 
Host PC * ill be In a Modem Linkage mode or Direct Line 
Linkage node; (2: setup the Modem Specifications and 
parameters Til :o imuaiize and access the modem connected 
to the Remote PC in ihose cases where a Modem Linkage 
mode will be used: '3j setup the Mouse Specifications and 
parameters 713 10 define the Remote PC's serial port num- 
ber where tne Remcte PC's mouse is connected in those 
cases where a serial mouse is present on a Remote PC and 
will be used to control a Host PC; and (4) setup the CALL 
LIST 715 of Host Units that may be accessed by the Remote 
PC 715. After these initial setup options have been 
completed, the Setup System 702 menu option may be 
selected to setup other system configuration options or to 
re-configure any options previously entered. 

When selected the Setup Main Menu 710 displays a list 
of four options. Tne Modem Specifications 711 menu setup 
option allows the baud rate, serial communications port 
number and modem Initialization string to be defined for the 
modem connected to the Remote PC. If the Remote PC wQi 
only operate in a Direct Line Linkage mode, then the modem 
fnftfaitVarion string would not be entered. 

When this option is selected, the software 712 automati- 
cally searches fcr a Hayes compatible modem connected to 
one of the senai pons on the Remote PC. If the modem does 
not respond :o ±e search, the modem's power is turned off 
(external mocemj. the cable between the Host Unit and 
modem has not been properly connected (external modem;, 
or a serial Interna conflict prevents access to the modem, 
the Setup process will assume that the Direct Line Linkage 
mode will be used. 

After the Modem Specifications are entered or modified, 
mis information is saved on the Remote PC's mass storage 
device. After the baud rate and modem reset string are set to 
desired values, the Esc key may be pressed to return to the 
Setup Main Menu 710. When the Esc key is pressed and the 
Modem Linkage optic n is specified, the software automati- 
cally initializes the Remote PC's modem using the baud rate 
and reset string specified. Thereafter, whenever the 
TVLIMCEXE program is first initiated, the modem 
installed in the Remote PC is initialized automatically, so 
there is no need tc re-run this menu option again unless the 
modem install ed in the Remote PC is changed or the modem 
does not properly connect with a Host Unit Once all 
required modification have been made to the Modem 
Specifications, the Esc key may be pressed to return to the 
SETUP menu. 

The Mouse Specifications menu option 713 permits speci- 
fying the Remote PC's serial port to which a mouse is 
connected. If no serial pon number is specified, the 
TVLINK.EXE software assumes that a mouse is not 
installed on the Remote PC- Otherwise, the TVUNK-EXE 
program tests for the presence of a mouse on the speciiied 
serial port and displays an error message, if the mouse 
cannot be found by the TVTJNK.EXE software. Once a 
valid serial port is speciiied. the port number selected is 
saved to a configuration file on the Remote PC's mass 
storage device, so that subsequent TVLIMCEXE sessions 
will Icnow if and where a mouse has been installed on the 
Remote PC. Once all required mollifications have been 
made to the Mouse serial cornmunications port, the Esc fcey 
may be pressed to return to the SETUP menu. 

The Update Call List 715 menu option permits each Host 
Unit that a Remote PC may access to be defined or changed 
716. Before a call can be placed to Host Unit, the Host Unit 
must be defined in the Remote PC's call list. 
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The specific lata dements that presently must be defined 
for each Hcs: Unit to be accessed include: (1) a location 
description, which is a user definable alphanumeric descrip- 
tion of the Host Unit being accessed such as "SERVER 
XY7T. "VAST TAPE Unit~ etc. (such descriptions help 
users with access to multiple Host Units more easily select 
a desired Host Uaur. (2) a dialing string needed to call and 
access zht modem at the site where the Host Unit is located 
in cases where the Remote PC operates in a Modem Linkage 
mode; O) an alphanumeric password that allows only autho- 
rized persons 'Aho have me password to access a specific 
Host Unit; and (A) the ED number of the Host Unit to be 
accessed. 

When a Host Unit is first installed, the default password 
has been pre -set prior to shipment to the eight digit serial 
number of the Host Unit, located on the label affixed to the 
bottom of the Host Unit. This numeric password must be 
specified in the Remote PC used to initially access an newly 
installed Host Unit. After a Host Unit has been successfully 
accessed using a correct password, the password may be 
changed as described later for block. 734. 

New call list entries may be added by using the Remote 
PC's down arrow key to go to the: last line of the call list 
which will be a blank line permitting the entry of data for the 
new Host Unit to be accessed. 

An entry may be deleted from the call list by using the 
Remote PC's keyboard up or down arrow keys to highlight 
the applicable line item and then pressing the F3 key to 
deiete the line from the call list. 

A call list entry may be changed by highlighting the 
applicable line item, then changing the data contained on the 
line, as desired. Various other keys may be pressed to speed 
the process of navigating through a call lisL A list of these 
keys is displayed m a pop up window whenever the user 
presses the Fl key. The pop up window is removed from 
screen when the user presses the Esc key. 

Once ail required modifications have been made to the 
call list, the Esc key may be pressed to return to the Setup 
Menu. 

The last menu option on the Setup Main Menu 710. 
Return To Main Menu 719. permits returning to the appro- 
priate System Main Menu VDM screen as discussed below 
beginning at block 742. 

The "Connection Options" menu line only appears on the 
Host System Mam Menu 755 when a active linkage exists 
between the Remote PC and a Host Unit. When selected the 
Connection Options Main Menu 720 is displayed that pres- 
ently contains various processing options. 

The Scan Screen History 721 connection menu option 
permits Host VDM screen data captured and transmitted to 
a Remote PC's VDM during a linkage session to be 
reviewed 722. 

When the Remote PC is linked with a Host PC. all video 
VDM screen data received orom the Host Unit is automati- 
cally logged to a screen history data file on the Remote PC 
presently called SCRN7HST.DAT. This file is automatically 
cleared whenever TVLXSKJEXE processing is first initiated. 

When the Display Screen History connection menu option 
is selected, the TVTJNK EKE program automatically acti- 
vates a VTEWHIST.EXE subroutine to view the SCRN- 
HIST. DAT Ale for the current TVTJN1CEXE processing 
session. This permits any VDM screen data captured since 
the TVTJNK.EXE program was kdtiztcd to be reviewed. 
The VDM screen history can be reviewed by using the UP 
and DOWN arrow keys. The Esc may be pressed to return 
to the Connection Options main menu 726. 

The Color Mode 723 connection menu option is selected 
to set the active Host Unit to a specific color or monochrome 
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display mode for purposes of capturing VDAC output for 
transmission :o 3 Rcracxc PC 

Five menu opticas are displayed whea the Color Mode 
723 menu opuon :s selected, which are (1) Normal Color 
Mode. (2, Bright Color Mode. (3) Green Signal Mode. (4) 
Red Sigoa. Moce and '5; Blue Signal Mode. These menu 
options g:'<-i a Remoie user the ability to either transfer 
VDAC text output 'o a Remote PC in normal intensity or 
high intensity ex or or in a monochrome mode using either 
the Red. Blue or Grtcz signal as the basis for decoding the 
VDAC output In ±c high intensity color mode, the fore- 
ground color: are displayed from the high intensity color set 
and the background color set remains normal. 

Normally ihe Host Unit is in a default display mode where 
the Host Unit's Viceo Processor only looks at the green 
color signai output of the VDAC This mode is one of three 
possible monochrome modes and normally yields the fastest 
possible video processing and the greatest probability of 
decoding video text data displayed by a color VDAC and the 
green signai ;3 me only signal for some monochrome VDAC 
output Blue and Red Signai Modes also yield the fastest 
possible video processing, but selecting these modes may 
cause a lower probability of decoding either the Blue or Red 
signals into characters because Host PC color applications 
typically use the Blue or Red signals less often than the 
green signal 

Selecting either the Normal or Bright Color Modes slows 
down the Vioeo CPU wmch must decode multiple signals in 
order to determine coior and the text character. As a result, 
text data may not appear as quickly on a Remote PC. when 
either color mode is sc;ected. However, selecting color 
assures the highest prooabiliry that the text data output of a 
VDAC will oe properly decoded 

Presently, for graprucs modes only the green VDAC 
output signal is used regardless of the menu option selected. 
As previously menQoDed adding additional hardware to the 
Host Unit's Video Processor circuitry would permit multiple 
color graphics transfers to a Remote PC in a reasonable 
period of tune. 

The UP and DOWN arrow keys may be used to change to 
a desired color or rcoaodnsomc display mode and then the 
Enter key may be pressed to select mat mode. 

After the desired dispia> mode option is selected off of the 
menu or the ESC key is pressed, processing is returned to the 
Connection Options menu 720. 

The Switch Host/Remote Mode 725 connection menu 
option is selected to set the mode that will be active after 
exiting from the main system menu when a connection to a 
Host Unit is active. Whenever TVLINICEXE processing is 
first initiated. Host mode processing is assumed. 

A menu 726 containing two possible modes appear when 
the Switch Host/Remote Mode 725 menu options is 
selected. The desired mode is highlighted using the Up and 
Down keyboard arrow keys and then the Eater key is pressed 
to select the mode. 

If the Remote menu option is selected, the last menu 
oprion on the system main menu will be changed from 4< Exit 
to Host mode" to "Exit to DOS" after exiting from the 
Connection Options Main Menu 720. Ob this basis, select- 
ing Exit to DOS option causes Remote PC processing to 
temporary exit out of the TVTJNK.EXE application to the 
PC's operating system (e.g. DOS) while continuing to 
maintain a connection to the Host Unit. Once DOS process- 
ing has been completed, a user may then return to the system 
main menu by typing "EXIT" at a DOS prompt For 
example, shelling-out tc DOS during a TVLINICEXE ses- 
sion would be useful if it became necessary to locate the 
directory where a file is located in order to transfer the file 
to a Host PC. 
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If the Host menu option Is selected, the last menu option 
on the TVLTNTCEXE menu will be "Exit to Host mode". 
When a Remote PC is placed in a Host mode, the Remote 
PC assumes coarroi of 'he Host PC. In this mode, the 
contents of the Remote PC's VDM screen reflect the con- 
tents of the Host PC's VDM screen and the Remote PC's 
keyboard and mouse 'assuming the mouse option is 
installed) is recur ec.td to lzpui keystrokes/mouse data to the 
Host PC. as opposed to me Remote PC. Accordingly, 
because the Remote keyooard. mouse and VDM act as if the 
remote user is sitting at ±c Host PC. there needs to be a 
sequence and/or combination of keystrokes (i.e. hot key) 
pre-defined that will cause ±c Remote PC to return back to 
a normal operating mode. Presently, tapping the left Shift 
key three times within 2 seconds acts as this hot key causing 
the Remote PC to return back to a normal operating mode. 
In this same regard, if a jsct taps the right Shift key two 
times within two seconds while in a Host mode, it will 
refresh the Remote PC's VDM screen by causing the Host 
Unit to transmit the entire current contents of the Host PC's 
screen. Normally, the Host Unit only sends any changes that 
have occurred on the Host PC's screen to minismzc the 
amount of data transmitted to a Remote PC. On occasion, 
variances in the Host PC's VDAC signals may cause the 
Host Unit to mis -interpret data displayed on a screen and 
send corrupted display data to a Remote PC. Tapping the 
right Shift key twice refreshes the Remote PC's VDM 
screen. 

Normally, when a Remote PC is in a Host mode, all key 
strokes entered into the Remote PC's keyboard are inter- 
cepted by the TVLTNK.EXE program and transmitted to the 
Host Unit, so that the Host PC can pass these keystrokes on 
to the Host PC. This process also permits the TVUNK.EXE 
to take other actions when necessary. As previously 
mentioned, multiple taps of the left or right shift keys 
presently cause the TV1JNTCEXE program to pop up and 
activate TVLIN1CEXE menu processing. In addition, when 
the "Print Screen" key is pressed. TVLJNK£XE presently 
permits this keystroke to pass through to the Remote PC's 
operating system, thereby permitting the Remote PC to print 
the contents of a Host PC's VDM screen to a printer 
connected to the Remote PC. Other such processing excep- 
tions can be made where necessary (through appropriate 
changes to the TvTJNlCEXE program code) to further 
enhance a Remote user's ability to more effective manage 
bom their Remote PC's and Host PC's resources. 

When a user is in a Host mode and presses the left Shift 
key three times within two seconds, the user is returned to 
the System Main Menu 741. This menu and other menus 
pop-up (i.e. overlay) over a portion of the Host PC's screen. 
Any Host VDM information displayed continues to be 
updated and visible behind the pop- up menu on the Remote 
PC's VDM screen until the Host PC's connection is termi- 
nated or the user temporarily exits to the PC operating 
system (e.g. DOS) as explained at blocks 753 and 754. 

After either the Host or Remote option is selected, pro- 
cessing is returned to the Connection Options menu 720. 

The File Transfer 727 connection menu option is selected 
to permit data file transfers to occur between the Host PC 
and Remote PC. File transfers from one directory location 
on a Remote PC to another directory location on the Remote 
PC can be accomplished by temporarily exiting to the PC's 
operating system, as described under the narrative for block 
726 above. File transfers from one directory location on a 
Host PC to another directory location on the same Host PC 
can be accomplished by selecting the "Exit to Host" option 
off of the system main menu, then using the Remote 
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keyboard final has been redirected to operate in place of the 
Host PC* 5 keyboard} to complete the transfer using, for 
example, the DOS COPY command. 

In order :c complete any file transfer between a Host and 
Remote PC. :±z Hos: Unit must have been property con- 
nected to one of ±e Host PC's serial ports. When this file 
transfer op'jen is selected, a menu containing two options 
appears -tax define the direction of the file transfer 728. The 
first option pemuts file transfer to occur from the Remote PC 
to the Host ?C. The second option permits file transfers to 
occur from me Host PC to the Remote PC. Hie transfer 
processing may be aborted by pressing the Esc key. If the 
Esc key is pressed, processing will return to Connection 
Options Menu 720- 

Once the direction of the file transfer has been selected, 
the entry of the flie specification is required to define the 
filers j to be copied. This specification is presently set to 
follow the oormzi DOS COPY command format used to 
describe a source file to be copied. For example, the source 
file could be specified as C:\NETWAREV.EXE. 
CVREPAIR.COM. orVVETWAREWREPAJR.COM. Once 
the source fiie has been specified, the entry of the target drive 
and full directory path where the files will be copied is 
presently required- 
After the source lies and target location have been 
specified file transfer processing is initiated automatically 
using a file transfer protocol such as XMODEM, which is 
known to persons familiar to the trade. File transfer pro- 
cessing is aborted if (I . the Esc key is pressed, (2) no source 
files exist or ths source ale drive and/or directory is invalid, 
(3) the Host Unit is sot properly connected to an active, 
available . Host PC serial port, or (4) the target drive and/or 
directory do not exist- Should processing be aborted an 
appropriate error message will be displayed and processing 
will return to the Connection Options Main Menu 720. 
Otncrwise. during me rile transfer process, the name of each 
file being transferred will be displayed. 

After a desirec file transfer process has been completed, 
processing is returned to the Connection Options Main 
Menu 720. 

The Cold Boot Host 729 connection menu option is 
selected to tempcrariiy interrupt all AC power to the active 
Host PC for approximately 15 seconds. A Host PC cannot be 
cold booted unless the Host PC's AC power plug is plugged 
into the AC Out receptacle on the back of the Host Unit. 

When this menu option is selected, the cold-boot request 
must be confirmed by entering "Y" in response to the 
question "ARE YOU SURE? fxTN)" 730. If *\V is entered 
in response to the question, cold-boot processing is aborted 
and processing returns to the Connection Options Mam 
Menu 720. If "Y" is entered, the Remote PC sends instruc- 
tions to Host Unit to :emporarily cut AC power to the Host 
PC for approximately 15 seconds. Once the power is 
restored, the Host PC reboots, the Host Unit returns a 
confirmation to the Remote PC that the cold boot process has 
been completed and processing returns to the Connection 
Options Main Menu 720. 

The Switch To New Unit 731 connection menu option is 
selected to switch from one Host Unit on a daisy chain to 
another Host Unit on the same daisy chain without termi- 
nating the linkage between a Remote PC and a Host Site. 

If only the currently active Host Unit at a Host Site is 
accessible, there is no reason to select the Switch To New 
Unit menu option. In cases where it is desired to switch from 
one Host Unit to another Host Unit at a different Host Site, 
the currently active modem linkage must be terminated by 
selecting the Terminate Call menu option 737. then estab- 
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lishing a new connection to the desired new site, as 
described, beginning ai block 703. 

When the Switch To New Unit 731 option is selected, a 
call list containing all Host Units defined using the same 
phone dialing string is displayed 732. 

The list of Host Units are displayed to permit switching 
between Host Units daisy chained together without the need 
to terminate the existing phone line connection. The Esc key 
may be depressed ec avoid switching to another Host Unit 
and return to the Connection Options Main Menu 720 The 
UP or DOWN arrow keys can be used to scroll through the 
list of Host Units denned. Once the desired Host Unit has 
been highlighted, the Enter key can be pressed to switch to 
the new Host Unit. 

If the new Host Unit is inaccessible or the password used 
for the new Host Unit is incorrect, an appropriate error 
message will be displayed on the Remote PC's VDM screen, 
the connection to ±c last active Host Unit will be restored 
and processing will return to the Connection Options Main 
Menu 720. Otherwise, the active connection will be 
switched to the requested Host Unit and processing will be 
returned to the Connection Options Main Menu 720. 

When the Change Unit Password option is selected 733. 
the system requests the entry of a new password for the 
currendy aenve Host Unit 734. The Change Unit Password 
option permits changing the currendy active Host Unit's 
password to a new password. When the password is 
changed, the call list entry for the applicable Host Unit is 
automatically updated to reflect the new password. 
Presently, when a Host Unit is manufactured, the password 
is initially set as the Host Unit's serial number. 

When the Change Unit Password option is selected, the 
user is requested to enter a new password of up to eight 
digits in length. Password change processing may be aborted 
by pressing the Esc key. When me Esc key is pressed, 
processing returns to the Connection Options Main Menu 
720. Otherwise, after a new password is entered, the Host 
Unit is updated for the new password. 

After the password has been updated, the user is requested 
to enter any changes to the number of attempts during a 
session that a user is given to enter a valid password before 
being lockedout of this Host Unit for the session. An entry 
of zero indicates that a user may be given an unlimited 
number of attempts to enter a valid password to access the 
Host Unit. For purposes of lock out processing, a session 
refers to the period between when a remote user first 
connects to a host site until that time the remote user 
terminates the connection to the site. 

Once the number of password attempts during a session 
has been updated, the user is requested to enter the number 
of concurrent sessions that may occur where a user fails to 
specify a correct password when accessing this Host Unit 
and is locked out of the Host Unit for the session. If the 
number of concurrent access lock-ups exceeds the specified 
number, the Host Unit will be electronically locked, until 
someone presses the action button on the front of the Host 
Unit When a Host Unit is electronically locked, any user 
attempting to access the Host Unit will be given a message 
that the Host Unit was locked due to a possible intruder and 
access will be denied even if a valid password is entered 
until the Action button on the front of the Host Unit is 
pressed. Also, when a Host Unit is eleco-onically locked, the 
Host Unit will emit a periodic audible alarm sound indicat- 
ing the Host Unit is locked until the action button on the 
-front of the Host Unit is pressed. An entry of zero indicates 
that the Host Unit should never be electronically locked. 
Whenever a Host Unit is successfully accessed by a Remote 
user, the concurrent session lockout counter is reset to zero. 
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Both the session lock and electrode lock are security 
measures designed :o prevent giving a means to unautho- 
rized intruders to guess a password to a Host Unit by 
limiting rhe q umber of guesses they can make and bringing 
the unauth on zed access attempts to the attention of man- 
age men: via ±e r;ectrctuc lockout procedure. 

After. ±c pas j-* era izc related access counts are entered, 
the applicable eail list entry is updated to reject the new 
password, and processing returns to the Connection Options 
Main Menu 720 

Woes the Change Temporary Password option is selected 
735. the system requests the entry of a new temporary 
password for the currently active Host Unit 736. 

In some cases a may be necessary to grant someone 
temporary access rights to a Host Unit. For example an 
independent network consultant at a remote site may need to 
temporarily access a .lie server to fix an unusual network 
problem. 

When the Change Temporary Password 735 menu option 
is selected, a user may specify an additional 'temporary" 
password and a mimber of hours that the password should 
remain in effect. The ternperary password entry may be 
aborted by pressing the Esc key If the Esc key is pressed, 
processing returns to the Connection Options Main Menu 
720. Otherwise, after a new temporary password is entered, 
the Host Unit is updaicd for the new temporary password, 
number of hours the password will remain in effect, and then 
processing returns to the Connection Options Main Menu 
720. 

The Terminate Call 737 connection menu option is 
selected to terminate the linkage to a Host site. When 
Terminate Call 737 mean option is selected, the call termi- 
nation request must be confirmed by entering "Y" in 
response to the question "ARE YOU SURE? (Y/N)~ 73$. If 
**>P is entered in response to Che question, call termination 
processing is aborted and processing returns to the Connec- 
tion Options Main Menu 72$. If "Y" is entered, the con- 
nection to the Host site is terminated causing both the Host 
and Remote modem to be reset, when in a Modem Linkage 
mode, and processing returns to the System Main Menu 701. 

The Clear Screen History 739 connection menu option is 
selected to cicar ail screens captured and stored on the 
Remote PC's mass storage device since TVXJNX.EXE 
processing was initiated or the screen history file was last 
cleared during an active session. 

When the Cicar Screen History 739 menu option is 
selected, the clear screen history request must be confirmed 
by entering **Y" in response to the question "ARE YOU 
SURE? (Y/N)" 740 If ~>T is entered in response to the 
question, clear screen processing is aborted and processing 
returns to the Connection Options Main Menu 720. If "Y" 
is entered, the screen history file is deleted, a new empty 
screen history fUe is created and processing returns to the 
Connection Options Main Menu 720. 

The Select Mouse Mode menu option 740 A connection 
menu option is selected to activate or deactivate recognition 
of a mouse connected to the Remote PC. When this menu 
option is selected, two menu options appear 740 B permitting 
the user to instruct the TVTJNKEXE software to either 
recognize or ignore mouse movements from the mouse 
connected to the Remote PC for purposes of transmitting the 
mouse movement data to control the Host PC. 

The Return To Main Menu 741 connection menu option 
is selected to return to me system's main menu or is 
automatically invoked if the connection to a Host Unit is 
lost. The processing options displayed on the system's main 
menu vary depending on the processing status and the 
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Remote/Host mode status 726. If a connection between a 
Remote Site and a Host site is lost due to a communications 
failure during conaecdon options menu processing 742. 
processing reruns to the System Main Menu at block 701. 
Otherwise, if :he system is in a Host mode 743. Host Mode 
Main Menu processing is initiated beginning at biock 755. 
If the system is m not in a Host mode 743. Remote Mode 
Main Menu processing is initiated beginning at block 750. 

Remote Mode Main Menu processing begins at biock 
750. This menu includes three processing options. If the 
Setup System processing option 751 is selected. Setup Main 
Menu processing begins at block 710. If the Connections 
Main Menu option is selected 752. connection optioo pro- 
cessing begins at block 720. If the EXIT TO DOS option is 
selected 753. control is returned to the PC's operating 
system (e.g. DOS. Windows™, etc.) until the Remote user 
key enters "EXIT** 754. After the user enters "EXIT" 
processing returns to the Remote Mode Main Menu 750. 

Remote Mode Main Menu 750 processing is terminated 
automatically if the communication connection between a 
Remote PC and a Host PC is lost 754A (e.g. due to a phone 
line failure) and processing is returned to the System Main 
Menu 701. Otherwise. Remote Mode Main Menu processing 
continues until either the Host Unit connection is terminated 
738 or the mode is switched to a Host mode 726 during 
Connection Options Mam Menu Processing 720. 

Host Mode Main Menu processing begins at block 755. 
This menu includes thrc= processing options. If the Setup 
System processing option 756 is selected. Setup Main Menu 
processing begins at biock 710. If the Connections Main 
Menu option is seieaed 757. connection option processing 
begins at block 720. If the Exit To Host Mode option is 
selected 758. the Remote PC's keyboard, mouse (assuming 
a mouse is installed on the Remote PC and activated as 
described at biock 740B) and VDM display are redirected to 
control the Host PC's keyboard/mouse and display the Host 
PC's video output 761 until the Remote user taps the left 
Shift key three tiroes within two seconds, as previously 
discussed at block 726. When the user taps the left shift key 
3 times, processing returns to the Host Mode Main Menu 
755. 

When a Remote PC is in a Host Mode the Remote PC's 
screen mode automatically switches to the screen mode (e.g. 
text or graphics) presently active on the Host PC. If the 
active screen mode is not supported by the TVLINKJEXE 
program or the Remote PC's VDAC. a error message 
indicating the Host PC has an unsupported video mode 
appears on the Remote PC If during the course of accessing 
a Host PC. the screen mode should change, the Host Unit 
would automatically notify the Remote PC that a change has 
occurred to a new video mode and then wait for a response 
from the Remote PC to confirm the Remote PC VDAC has 
been switched to the new video mode before further video 
data transfers occur. 

Host Mode Main Menu 755 processing is terminated 
automatically if the communication connection between a 
Remote PC and a Host PC is lost 760 and processing is 
returned to the System Main Menu 701. Otherwise Host 
Mode Main Menu processing continues until either the 
connection is terminated 738 or the mode is switched to a 
Remote mode 726 during Connection Options Main Menu 
Processing 720. 

FIGS. SA and SB show examples of the current protocol 
implemented between the Host Unit and the TVLINKJEXE 
program running on a Remote PC. Numerous alternative 
approaches known to those of skill in the art could have been 
chosen to implement a protocol for the apparatus. 



Values used m the protocol are shown as hexadecimal 
numbers. Initially, once a modem connection has been 
established bcr~czz uhc Remote PC and the Host Unit 00, all 
Host UniL'> at a site constantly monitor data from the 
TVLINTC EXE program waiting for a correct access request 
addressed :o :hey Host Unit's ID. 

Reference SfrT represents data which the TVLXNK.EXE 
program sends to :ne Host Unit. Reference 806 represents 
data which the Hos: Unit sends to the TVLINTC EXE pro- 
gram. Tne TvUNXEXE program accesses a given Host 
Unit by sending a four byre packet as shown at references 
800. 801. Tne first rwc bytes (hex 70 and hex 00) indicate 
that access is recucstec and is followed by two bytes which 
contain the requested unit's identification number. This 
number is split ;zio >o bit quantities (nibbles;: Hex 40 
plus the high nibble ''shifted down 4 bits) and hex 50 plus the 
low nibble. Tne Host Unit on the chain with a matching 
identification number will respond by unchaining and 
directly connecung :o die data line. This Host Unit then 
requests a password from TVLINK-EXE program on the 
Remote PC. 

A hex Fr 802 is reserved as a BREAK character. When 
this character is received, it indicates that the next byte is a 
command or status byte. Tne hex 06 following 802 is a 
request for password and is followed by two bytes 803 
which form an encryption. The TVLIN1CEXE pro gram then 
sends an encrypted password 804 to the Host Unit If this 
encrypted password is correct. ±c Host Unit sends hex FF 
and hex 10 bytes $05 which means that the Host Unit is 
ready and that the Hos: Unit has been successfully accessed. 

Although only one password is requested as shown in the 
figure, in the current imp :e mentation, three to a ten pass- 
words will be processed each with a unique encryption key. 
Only after all pas sw ores are correctly received will the Host 
Unit send the ready status 805. This password protocol 
approach insures added security tc the Host Unit access. If 
a password is incorrect. Aez no more password requests will 
occur and the Remote PC wul not be permitted access to the 
Host Unit 

To avoid madvcr.ect access to other Host Unit's while 
having access to a given Host Unit, hex 70 is never trans- 
mitted to the Host Unit by TVIiNTCEXE program (other 
than during an access request 800). Instead, the two byte 
packet 810 is sent which is interpreted as a single byte value 
of hex 70. 

Reference 827 represents data which theTVUNK. EXE 
program sends to the Host Unit. Reference 838 represents 
data which the Host Urut sends to the TVUNK.EXE pro- 
gram. After the host sends the ready status 805. the 
TVLINK.EXE program car: now issue commands to the 
Host Unit 

To enter remote access in :ext mode, the two byte com- 
mand packet 820 is sent It is composed of the BREAK 
character (hex FF; and the command byte (hex 33). The Host 
Unit now begins a remote access mode. In this mode, data 
bytes sent to the Host Unit from the TVUNKEXE program 
are interpreted as keyboard scan codes which are translated 
and sent to the Host PC as keyboard signals. The hex value 
IE at 821 is a scan code generated when the *A' key is 
pressed. The hex value 9E at 822 is a scan code generated 
when the 'A' key is reieased. 

Also, in remote access mode, video text data is captured 
and sent to the TVIINTCEXE program 838. This video data 
stream is composed of several parts. First the screen char- 
acter address is sent which is the BREAK character 830 
plus the two byte address 831. This address 831 is shown as 
zero, but since it is assumed upon entering remote access 
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mode thai me Remote PC's monitor screen has been blanked 
by the TVIJNTC-EXE program for the first screen's worth of 
data, no spaces will be sent. Thus, this starting address 831 
may not necessarily be zero but will indicate the address of 
the first ncpoLank character encountered. 

Next, coicr acrfoute information is sent (the BREAK 
character 832 with :he attribute S33). This attribute byte is 
a hex CO value ;ummcd with the 6 bit color attribute. Each 
bit can be represented by the form of "llrgbRGB" where the 
two most significant bits " 11" toncone). indicate that this is 
a color attribute byre where r.g and b represent red, green 
and blue foreground coior bits, and R. G. and B represent the 
background coior bits, as more fully discussed in the nar- 
rative supporting FIG. 5G and 5H. The value shown at 833 
(hex F8> represents white on black. The two most significant 
bits (hex CO) :s masked off (set to zero) leaving hex 38 or 
00111000b. Ail foreground bits (rgbj equal one and all 
background bits 0RGB) are zero, thus meaning white on 
black. 

After the address and coior information is sent, character 
code values, such as ASCII codes, follow. Reference 834 
shows the hex representation of an "A~ followed by a hex 42 
which represents a "B" character. After mis. there is a color 
change, so 835A is sent, composed of a BREAK character 
and the new color byte. In this case the hex Fl represents 
blue on black. The two most significant bits (hex CO) is 
masked off (set to zero) leaving hex 08 or 00001000b. Only 
the foreground biue bit (rgb) is equal to one and all back- 
ground bits 'RGB) are zero, thus biue on biack. After this a 
hex 43 representing a "C* character is sent 835B. This 
continues until and an entire screen's worth of data is sent 
after which only the changes "will be sent ( thus reference 831 
may take on non-zero values;. Hex value FF. used in this 
mode at 838. as the break character, was selected because 
this value docs not represent a valid character. 

In addition to the scan codes 821, 822 being sent by 
TVUNK-EXE program to the Host Unit 827. there are 
several commands which can also be sent. A refresh-screen 
command fhex Fl) 823 insffucts the Host Unit to resend an 
entire screen of video text as if remote access mode has just 
been invoked. This begins with another address packet 836 
(identical to 830) to be sent followed by color information, 
then characters, etc 

Another type of command 824 sends serial mouse data 
825 to the Host Unit to be forwarded to the Host PC's serial 
mouse input port The content of this mouse data 824 in not 
important to either the TVLLMC EXE program or the Host 
Unit, it is simply passed through to the Host PC's serial 
mouse port. 

As the Host Unit is capturing video text data, the Host 
PC's video mode may change to graphics mode at which 
point this information is transmitted to die TVXJN1CEXE 
program as indicated at reference 837 (a BREAK character 
plus the graphics mode sums: hex S3). At this point the 
Host Unit will not send any more video text information, but 
will continue to process scan codes and commands received 
from the TVLINK.EXE program. In the current 
implementation, the TVLINKJlXE program will end 
remote access text mode by issuing a hex FF 826 (which in 
this usage, is not a BREAK character) and begin remote 
access graphics mode. Then, the Host Unit sends a ready 
status (see 805) to indicate it is ready to process another 
command. 

Remote access graphics mode begins by the 
TVIJKKJEXE program sending 84$ (a BREAK character 
plus a hex 34 remote access graphics command). At this 
point the Host Unit sends video graphics data 855 and will 



process scan cooes, mouse information or other commands 
846. Scan codes are incw: at references 841. 842. the 
refresh command causing the graphics screen to be Re- 
painted" is show a at 843 izc 'Me end graphics video mode 
command show- at S45 Mouse data is not shown but can 
also be processed. 

The primary difference r>e:ween graphics processing and 
text processing, is :ha: -nc 3REAK character value is now 
a hex 2A. This value w as chosen because a hex FF. which 
means ail pixels are on. :s a common occurrence in graphics 
mode, so the value hex 2 A was chosen instead. This mode 
begins by sending ^he starting address (the break character 
850 with two bytes of grarmcs address information 851). It 
is assumed that the Remote PC's display screen is blank, and 
so only no q- zero graphics da: a bytes are sent. The address 
value 851 may be other than the zero value shown. 

In the most prcferrec embodiment, only graphic "snap 
shots" are taken. Tnai is, after the address is sent and the 
graphics data 852 has been completely sent, video graphics 
data will cease, unci a refresh screen command 843 is 
received, at wh.ch use the graphics data is captured and 
sent again (see 853,. Reference 854 shows that the Host 
PC's video mode has crjmged back to text mode (a break 
character plus the text mode status, hex 85). Then, the 
TVLJNK.EXE program will end remote graphics mode via 
845 and start the remote tex: mode (see 820). Note that for 
the remote grapnics mode, if a graphics data byte equals a 
hex 2 A (same as the breai character) then a two byte packet 
is sent, which .nciuces the break character (hex 2A) fol- 
lowed by the hex vaiue A2. The TVLINK.EXE program will 
interpret this to be a hex 2 A data byte. 

Either the tex: or grapmcs mode can be ended at any time 
by issuing the hex FF character 826.845. 

It is possible that the viceo mode may change to an 
unrecognized video moce cr video may cease altogether (Le. 
by arming the Host PC oS or Us connecting the video cable). 
TVLINKEXE is nodnec of tins event (similar to 837 and 
854) by sending a 3REAX character followed by a hex 89 
(no video present) or hex SB (unknown video mode). 

The file transfer rcoce .s entered in a fashion similar to the 
video modes just its en bed (Le. a BREAK character fol- 
lowed by the command eyre;. The Host Unit simply passes 
TVUNK. EXE file data trough to the Host PC or vice versa 
after the TVTTLE-EXE program has been invoked on the 
Host PC to handle aic transfers. The TVLINK-EXE converts 
all (Host Unit bound) hex "0 values to the two byte packet 
shown at 810 which the Host Unit will convert to a single 
hex 70 value before sending it to the Host PC. If 
TVLINK-EXE sends a nex FF character, this will end file 
transfer mode. So. (Host PC bound) data values of hex FF 
must be convened to a two byte packet of hex F0 plus hex 
OF 811. which the Host Unit -will convert to a single value 
of hex FF before sending to the Host PC and TVFILEJEXE 
program. Other than these exceptions, the file transfer pro- 
tocol is the responsibility cf :he TVLINKEXE and TVFI- 
LE.EXE programs. In the current implementation, a modi- 
fied XMODEM protocol is employed for file transfers with 
the data packet size changing according to the number of 
errors encountered (line aoise>. The XMODEM protocol is 
an industry standard familiar to persons in the trade. 

The current Host Unit protocol could be modified to 
employ a higher level of data transmission error detection 
and acknowledgment to lessen the possibility of communi- 
cation line noise causing data errors. 

FIG. 9 represents an alternative embodiment of the 
present invention to the preferred ernbodiment discussed 
above in which a Host Unit captures and decodes the Host 



PC's VDAC video raster output signal. Under this approach, 
an Expansion adapter Card (EC) could be inserted into one 
of the available interface adapter card buss slots (e.g. 16 or 
32 bit slots) within the Host PC and capture the digital video 
data directly from the Host PC's buss as it is being send to 
the Host PC's VDAC. In this case the EC would be designed 
so as not to interfere with acrmaJ Host PC processing, but 
wouid simply "listen-in" on the Host PC's buss and imme- 
diately transmit any video data detected to the Host Unit via 
a direct cable linkage between a Host PC video data inter- 
face (e.g. serial) port and a Host PC interface port on the EC 
As shown on FIG. 9. a possible embodiment of the EC 
would contain it's own microprocessor 902. Operating sys- 
tem software (within the associated EPROM memory 901) 
would monitor video activity being sent to the Host Unit's 
VDAC. Any video data dti^cicd on the buss 910 would be 
sent out through the EC's video data output receptacle 903 
to the Host Unit's 904 ( via a video data input receptacle) via 
903. Because of possible differences in data transmission 
rates berween the speed of the Host PC's buss and the speed 
at which data can be transmitted to a Host Unit, two levels 
of data buffering is included. To capture the video data from 
the Host PCs buss 910. several first-in first-out (FIFO's) 
buffers 912. 914. 916 would be used. The microprocessor 
then reads from these FIFO's, processing the data to place 
it in a form ready for transmission, and stores this data in 
memory 900. The data in this memory is then transmitted to 
the Host Unit. 

The EC contains battery back-up. so that any data existing 
in the buffer could continue to be transmitted by the EC to 
the Host unit even in cases where the Host Unit has failed. 

Digital video data received from the EC by the Host Unit 
would be stored in the Host Unit and forwarded to the 
Remote PC following the same procedures described for the 
preferred embodiment. However, the Host Unit wouid no 
longer need to access ana decode the VDAC output from the 
Host PC since in this alternative embodiment the digital 
video data would be supplied by the Host PCs EC 

Standard VDAC memory usage is as follows. This 
memory (addressed by the Host PCs microprocessor) 
resides on the VDAC Monochrome text data is written to 
memory addresses starting at B 000:0000. Whereas color 
text data is written to addresses starting at B 800:0000. 
Standard VGA mode color graphics data is written to 
addresses staning at ACOOiOOOO and this represents a 64K 
block (which is not large enough for VGA) and is bank 
switched to allow total access to the entire VDAC graphics 
memory. Bank switching is accomplished by writing certain 
data bytes to VDAC port addresses. 

When data is written to the VDAC's video memory, 
whether in text mode or graphics mode, mis data will also 
be written to the EC's FIFO's. The Host PC's 20 bit buss 
address is split berween two FIFO's. The 16 bit buss data 
value 911 will be written to FIFO 912. The 16 bits of the 
buss address 913 are also written to FIFO 914. The remain- 
ing 4 bits of the buss address combined with certain control 
signals 915 are written to FIFO 916. These control signals 
are composed of a single -byte access line and its associated 
high or low byte line, the write port signal, and the write 
memory signal. These signals 915 are analyzed (not shown) 
so that data will be wriaen to the FIFO's only when 
addresses AOOOrOOOO through BFFF:FFFF. as well as VDAC 
port addresses, are written to by the Host PCs buss. Note 
that FIFO's need not be used and could be replaced by other 
circuitry to accomplish the same function. 

The three FIFO's are then read by the microprocessor 902 
and analyzed to determine the kind of VDAC access, and 



57 

writes apprcpr-a^ output data to the memory 960. This 
memory :s trearec as a circular buffer. When the buffer is not 
empty, then lata j seat vm 903 to the Host Unit 904. Thus, 
new data is acccd b> 902 when it is received from the 
FIFO's, while previously processed data is forwarded to the 
Host Unit, 

As an aiternauve emrxxliment to a separate EC. the 
functions of tr.e separate EC could be incorporated on to a 
singie Hcs: VI) AC. In :rus case the combination VDAC 
would have r~c ojtpu ports, namely a VDM interface port 
and a Host L'zii interlace port for transmitting the digital 
video informal: oz from the Host PC to the Host Unit via an 
interface cabie. 

An alternant e enibocumcat of the Host Unit permits the 
Hos: Unit to be more portable and easily connectabie to a 
Host PC in cases where one Host Unit was used to facilitate 
access to more man one Host PC. This alternative embodi- 
ment is hereinafter referred to as a "Portable Host Unit". A 
Portable Host Urii would typically only be connected to a 
Host PC in cases where one of the Host PC's at a Host Site 
had failed and a repairman needed temporary access to the 
failed Host PC remotely to initiate repairs. Once the repairs 
were completed or the problem with the Host PC diagnosed, 
the Portable Hos: Urn: couid be removed from Host PC and 
remain at the Host site mril another PC failed. 

Under one possfcie alternative embodiment of the Host 
Unit, a buss interface slot couid be incorporated into the 
internal circuitry of r.: Portable Host Unit This slot could 
then permit a standarc -Sternal modem (commonly inserted 
into PC bus: slots and familiar to persons in the trade) to be 
inserted into the Portable Host Unit and thereby eliminate 
the need for an external modem. This approach eliminates 
the extra steps required for personnel at the Host Site to hook 
up an external modem to effect remote access. In addition, 
the Portable Host Urn: ^ould have an acoustical coupler 
(familiar to persons familiar with the trade) which would be 
incorporatec into the Portable Host Unit's case and con- 
nected to the Portable Host Unit's internal modem to permit 
a standard tciepnone neadset to be used (instead of a 
standard telephone line: to connect a Remote PC to the 
Portable Host Unit, An acoustical coupler connection is 
preferred over a reiepnooe line connection due to the exist- 
ence of intelligent business phone systems. Many such 
systems have connectors, cabling and/or signals that are not 
compatible with standard PC modems. Accordingly, it 
would be unpractical for a Remote PC to establish a linkage 
to the Portable Host Cmt unless the Host PC were moved to 
a location where a telephone jack existed or a long phone 
cabie was run to me Portable Host Unit from wherever an 
available pnone jack exists. An acoustical coupler permits a 
connection to be made :o a Remote PC simply by placing the 
most convenient telephone's headset at the Host site into the 
acoustical receptacle on the Portable Host Unit. 

Under this alternative embodiment, the Portable Host 
Unit would be connected to a Host PC as described in the 
narrative supporting FIG. 1. except (1) no direct line linkage 
would apply. (2) the modem at the Host Site would not be 
plugged directly into a telephone line and (3) no other Host 
Unit's would be daisy-chained to the Portable Host Unit 
After the Portable Host Unit was attached to the Host PC. the 
TVTRAZN.EXE program couid be initiated on the Host PC 
and the training process completed as described in narrative 
for FIG. 6. If this training process had been previously 
completed for this Host PC and the training parameters were 
stored in the Remote PC that will access the Host PC. as 
described below, the training process need not be repeated, 
after the Portable Host Unit is re-attached to the Host PC. In 
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this case, the accessary training parameters would be 
uploaded from Ac Remote PC to the Host Unit via the 
TVLINK.EXE program when the connection is first 
established, as described below. 

After the Portable Host Unit is connected to the Host PC 
and the training process completed, if applicable, a call 
would be initiated from the Remote PC to the most conve- 
nient phone number and phone extension, if applicable, at 
the Host Site where the Portable Host Unit is located. The 
person answering the call would place ihe telephone headset 
on the acoustical coupler of the Portable Host Unit to 
complete the telephone line linkage between the Remote PC 
and Portable Host Unit If the training parameters for the 
Host PC being accessed are stored on the Remote PC's mass 
storage device, the parameters would be up-loaded auto- 
matically by the TVUNK.EXE program to the Portable 
Host Unit's non-volatile RAM storage, immediately after 
the connection to the Portable Host Unit is established. 
Otherwise, the training parameters would be automatically 
down-loaded from the Portable Host Unit's non-volatile 
RAM to the Remote PC's mass storage device for use io 
cases where future access may be required to the Host PC to 
eliminate the need for users at the Host Site to re-train the 
Portable Host Unit. Once the connection to the Portable Host 
Unit and the required training parameters have either been 
up-lcadec or down-ioadsd. the Remote PC will have access 
to the Portable Host Unit consistent with any other Host 
Unit, as previously discussed. Ooce Host PC is processing is 
complete, the Remote PC user would terminate the connec- 
tion via the TVLINK.EXE program (see narrative for block 
754 A;, the Portable Host Unit would beep three times after 
the connection has ended, and someone at the Host Site 
would then remove the telephone headset from the acous- 
tical coupler and reaim it to it's telephone cradle. 

With regard to TVUNK.EXE processing on a Remote 
PC. when a call list is updated (see narrative for block 715). 
a symbol such as will be used as part of the dialing string 
to indicate a call is being placed to a Portable Host Unit. 
When a call is placed to a Host Site (sec narrative for block 
704) containing this symbol as part of the dialing string. 
TVUNK.EXE will either up-load or down-load Host Unit 
training parameters to or from the Portable Host Unit, 
automatically associate the stored training parameters with 
the call- list entry, and follow the procedures necessary to 
establish a connection to the Portable Host Unit via an 
acoustical coupler. In addition, the TVLXN1C EXE program 
will preclude selecting the TVUNK.EXE menu option 
permitting a Remote user to switch between Host Units (see 
narrative for block 731) . since other Host Unit's cannot be 
presently daisy-chained to a Portable Host Unit. 

The internal circuitry of a Host Unit presently provides a 
general data interface port, herein referred to as an "AUX" 
port to send data out of the Host Unit and receive data into 
the Host Unit from external devices. Presently, this AUX 
port has several intended uses. 

First, this AUX port could be programmed by the Control 
CPU to interface with a transmitter, such as an X-10 
transmitter, familiar to persons in the trade, to permit a 
Remote PC to control devices external to a Host Unit. For 
example, a Remote User could select a menu option pro- 
vided by the TVUNK.EXE program causing power to be 
temporarily interrupted to remote print servers on a network, 
forcing the print servers to reboot and reattach to a computer 
network that has failed and been successfully re -started. In 
this example, data required by the X-10 unit to interrupt 
power to desired print servers would be sent by software 
operating in the Control CPU to the X-10 unit connected to 



